我正在尝试找出构建易于维护和可测试的架构的最佳方法。在经历了几个项目之后，我看到了一些非常糟糕的架构，我想避免在我自己的项目中犯下 future 的错误。
假设我正在构建一个相当复杂的三层应用程序，并且我想使用 DDD。我的问题是，我应该在哪里放置我的业务逻辑？有人说它应该放在服务(服务层)中，这确实有道理。拥有许多遵循单一职责原则的服务是有道理的。
但是，有人说这是一种反模式，不应在服务层实现业务逻辑。为什么是这样？
假设我们有 IAuthenticationService其中有一个方法是 bool UsernameAvailable(string username)签名。该方法将实现所有必需的逻辑来检查用户名是否可用。
根据“这是一个反模式”人群，这里的问题是什么？
最佳答案
如果您将所有业务逻辑放在(隐式无状态)服务层中，那么您就是在编写过程代码。通过将行为与数据分离，您就放弃了编写面向对象的代码。
这并不总是坏事:它很简单，如果您有简单的业务逻辑，就没有理由投资于成熟的面向对象 domain model .
业务逻辑越复杂(域越大)，过程代码变成意大利面条式代码的速度就越快:过程开始使用不同的前置和后置条件(以不兼容的顺序)相互调用，并且它们开始需要不断增长的状态对象。
Martin Fowler's article on Anemic Domain Models可能是理解为什么(以及在什么条件下)人们反对将业务逻辑放在服务层中的最佳起点。
关于domain-driven-design - 将业务逻辑放在 DDD 的何处，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6891019/