我正在尝试找出构建易于维护和可测试的架构的最佳方法。在经历了几个项目之后，我看到了一些非常糟糕的架构，我想避免在我自己的项目中犯下未来的错误。
假设我正在构建一个相当复杂的三层应用程序，并且我想使用 DDD。我的问题是，我应该把我的业务逻辑放在哪里？有人说它应该放在服务（服务层）中，这确实有道理。拥有许多遵守单一职责原则的服务是有意义的。
但是，有人说这是一种反模式，业务逻辑不应该在服务层实现。这是为什么呢？
假设我们有IAuthenticationService，它有一个带有bool UsernameAvailable(string username) 签名的方法。该方法将实现所有必需的逻辑来检查用户名是否可用。
根据“这是一个反模式”的人群，这里有什么问题？
【问题讨论】：
标签： domain-driven-design business-logic service-layer
DDD 必须有 4 层：表示层、应用层、域层和基础设施层。
表示层向用户呈现信息，解释用户命令。
所有依赖于用例逻辑（应用程序实体、应用程序工作流组件，例如 DTO、应用程序服务）都进入应用程序层（应用程序逻辑）。该层不包含任何业务逻辑，不保存业务对象的状态，可以保存应用任务的进度状态。
所有不变的用例逻辑（业务实体、业务工作流组件，例如领域模型、领域服务）都进入领域层（领域逻辑）。这一层负责业务领域和业务规则的概念。
基础设施层可能有 IoC、缓存、存储库、ORM、密码学、日志记录、搜索引擎等。
【讨论】：
如果您将所有业务逻辑都放在（隐式无状态）服务层中，那么您就是在编写过程代码。通过将行为与数据解耦，您就放弃了编写面向对象的代码。
这并不总是坏事：它很简单，如果您有简单的业务逻辑，则没有理由投资于成熟的面向对象domain model。
业务逻辑越复杂（域越大），过程代码转换成意大利面条代码的速度就越快：过程开始以不同的前置条件和后置条件（以不兼容的顺序）相互调用，并且它们开始需要- 增长状态对象。
Martin Fowler's article on Anemic Domain Models 可能是了解人们为什么（以及在什么情况下）反对将业务逻辑放入服务层的最佳起点。
【讨论】：
服务层本身并不是一种反模式，它是放置业务逻辑某些元素的非常合理的地方。但是，您确实需要谨慎设计服务层，确保不会从域模型和组成它的对象中窃取业务逻辑。
通过这样做，您最终可以得到一个真正的反模式，一个贫乏的域模型。 Martin Fowler here 对此进行了深入讨论。
您的 IAuthenticationService 示例可能不是讨论该问题的最佳选择 - 围绕身份验证的大部分逻辑都可以视为存在于服务中，并且与域对象没有真正关联。一个更好的例子可能是，如果您有某种 IUserValidationService 来验证用户，或者更糟糕的服务是处理订单之类的事情 - 验证服务正在从用户对象中剥离逻辑，而订单处理服务正在从您的订单对象，也可能来自代表客户、交货通知等的对象...
【讨论】：