认识达内从这里开始

领域驱动设计是目前大多数软件开发程序员都在学习和使用的一种编程开发方式，而本文我们就通过案例分析来简单了解一下，领域驱动设计应用注意事项分析。

1.Thedomainmodellayer

负责表达业务概念、业务场景和业务规则。这一层会将技术细节传递到基础设施层，这一层控制、反映业务场景，是业务软件的核心。

领域模型层是表达业务的地方，在编程上体现为捕获数据和行为(具有逻辑方法)的领域实体的类库

遵循持久性无感知和基础设施无感知原则

领域模型层必须完全忽略数据持久性细节，这些持久性任务应由基础设施层执行，因此，此层不应直接依赖基础设施，这意味着一个重要规则是领域模型实体类应为POCO。

领域实体不应直接依赖于任何数据访问基础框架(EF、NHibernate)，理想情况下，您的域实体不应继承自或实现任何基础设施中定义的任何类型。大多数现代的ORM框架(例如EntityFrameworkCore)都支持这种方法，因此您的领域模型不会与基础设施耦合。

领域模型中遵循持久性无感知原则很重要，但也不应忽略持久性问题

理解物理数据模型以及它如何映射到您的实体对象模型仍然非常重要，否则你的设计将会是空中楼阁。而且，大多数时候你将本应该采用关系数据库的设计直接迁移到NoSQL或面向文档的数据库，领域模型层很可能不适用(基于存储技术和ORM技术，您的实体模型仍然必须遵守一些约束条件)。

2.ApplicationLayer

定义软件要执行的工作，并引导(可表达的领域对象)解决问题。

该层对对业务负责，有时会与其他系统的应用程序层交互。

该层保持薄：它不包含业务规则或知识，而仅协调任务并将工作委托给下一层的域对象协作;

它没有反映业务情况的状态，但是可以具有反映用户或程序的任务进度的状态。

微服务的应用层在.NET中一般表现为WebAPI，webapi实现交互、远程网络连接、为UI/Clientapp提供的外部请求中转。

再次强调webapi不应该包含业务规则或领域知识(尤其是用于事务或更新的领域规则)，这些应归领域模型类库所有。

应用层只能协调任务，不能保存或定义任何域状态(域模型)，它将业务规则的执行委托给领域模型类本身(聚合根和域实体)，这将终更新这些域实体中的数据。

总体来看，应用层是为实现前端用例的地方。

3.Theinfrastructurelayer

基础设施层:定义如何将初保存在领域实体中的数据持久化到数据库或者其他存储结构的过程。

一个示例是使用EntityFrameworkCore代码实现存储库模式类:该存储库模式类使用DBContext将数据持久存储在关系数据库中。

根据前面提到的持久化无感知和基础设施无感知原则，基础设施层不得“污染”领域模型层。

再次强调：必须保持领域层实体对基础设施层框架的无感知状态，领域模型层类库应该只包含领域代码，而只有POCO实体类可以实现软件的核心，并且与基础设施技术完全脱钩。

4、总结

在DDD中，应用层依赖于领域和基础设施层，而基础设施依赖于领域层，但是领域层不依赖于任何层。

只在领域层编写业务规则和通用的领域知识，而应用层负责针对软件的目标来组合、协调领域层的业务规则。

领域层的领域实体、值类型、聚合根反映了真实业务的核心，需要用一种通用的语言来定义，这样不管应用层多么复杂，核心领域层自岿然不动。

领域层不能直接依赖与基础设施层，现代ORM框架一般都提出仓储模型来帮助领域层和技术设施层解耦。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。