代码拉取完成，页面将自动刷新
本人早期接触领域驱动设计(Domain-Driven Design)是有一些抵触的，可能是长期固有的以数据驱动的三层架构思想作祟，认为引入DDD会使得应用系统架构变得复杂化。但是，经过深入研究发现DDD的设计方法在面对复杂的业务需求时会有其独特的优势。
当经典的三层架构在遇到复杂的业务需求时，不可避免的会造成其业务逻辑层的臃肿和难以维护（后期），DDD正好可以很好的解决这一问题。应用DDD的设计思想，我们可以先和领域专家一起提炼出稳定的软件内核（领域模型），再围绕内核向外进行封装提供用户所需的服务，对内提供内核运行所需的诸如持久化、网络通信等各种基础设施服务，最终形成一个完整的软件功能。
另外，DDD作为一种软件设计方法，通过领域模型的划分与构建，可很好的做到模型间的高内聚、低耦合，增强系统的可扩展性和稳定性，这些都与微服务架构的特性不谋而合，可为微服务架构的落地提供了很好的解决方案。所以，我们也可以看到，随着微服务的流行DDD也越来越多的被应用与实战项目中。因此，我就想花一点空闲时间，基于我个人对于DDD的理解与思考搭建一个基于.NET 的项目脚手架，供大家来一起参考、讨论。
最后，DDD和以数据驱动的分层架构并非谁好谁坏的区别，而是各自有其适用的场景，比如我始终认为如果仅针对某个表单的CURD来说，以数据驱动的分层架构仍是更优解。
如上图所示，我们将应用整洁架构的理念来进行DDD应用程序分层，其核心思想就是应用程序中各层之间的依赖关系都向内流动，越往里，依赖越低，代码级别越高。外层代码依赖只能指向内层，内层不知道外层的任何事情。
前面我们说了整洁架构的主要原则 --> 依赖原则 ，但是在实际项目中如何落地，这里我试着基于.NET 8搭建了示例项目 Sgr.Modules.UPMS，最终结构如下图所示：
图左侧包括核心层和组件层两部分，属于应用程序基础框架，业务无关，为DDD应用落地提供基础的支撑。
核心层：定义DDD应用落地所需的基础类型，包括一系列基类、通用接口和常用帮助类。例如：
组件层：包括多个具有诸如Events、BackgroundsTasks、ORM等某一特定功能的类库。
另外，图右侧内容才是我们本次讨论的重点，我们将DDD程序分为领域模型层、应用服务层、基础设施层和用户界面层共四层。
领域模型层：它仅依赖程序框架中的核心层（用以继承核心层中定义的相关基类或接口），它是核心业务逻辑的集中地，具体包括：
应用服务层：它仅依赖领域模型层，它作为中间层是领域模型层和外层之间的“粘合剂”，它不包含业务领域知识，它仅负责通过对领域模型对象的编排来实现整个系统的所有用例。我们采用CQRS的方式来构建应用服务层，具体包括：
基础设施层：它依赖赖程序框架中的相关组件以及DDD中的领域模型层和应用服务层，它负责实现领域模型层和应用服务层中定义的接口，它聚集了各种底层资源相关的服务和能力为业务提供所需的技术支撑能，比如：
用户界面层：它依赖领域模型层和应用服务层，它面向前端用户提供服务和数据适配，具体功能包括：
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。
