2023年7月18日发(作者：)

DDD（DomainDrivenDesign）架构设计⼀、为什么要分层分层架构是所有架构的⿐祖，分层的作⽤就是隔离，不过，我们有时候有个误解，就是把层和程序集对应起来，就⽐如简单三层架构中，在你的解决⽅案中，⼀般会有三个程序集项⽬：、 和 ，然后把这三个程序集看成⼀个层，这没什么不可以，但当项⽬复杂的时候，如果还按照这种⽅式的话，你的程序集中的⽂件夹会越来越多，程序集也会越来越⼤。当你的视野跳出这个程序集的概念后，你会发现，层不只是和程序集对应，也和解决⽅案⽂件夹，或者是整个解决⽅案对应，⼀个层甚⾄可以对应⼀个系统。分层的⽬的即为了“⾼内聚低耦合”的思想。⼆、微软经典的三层架构任何⼀个.net都知道的微软的三层架构，三层架构就是把业务划分为界⾯层（User Interface layer）、业务逻辑层（Business Logic Layer）、数据访问层（Data access layer）。如下图各层的作⽤：界⾯层(UI)：主要表⽰WEB⽅式，也可以表⽰成WINFORM⽅式;如果逻辑层相当强⼤和完善，⽆论表现层如何定义和更改，逻辑层都能完善地提供服务。主要对⽤户的请求接受，以及数据的返回。业务逻辑层(BLL)：主要是针对具体的问题的操作，也可以理解成对数据层的操作，对数据业务逻辑处理，如果说数据层是积⽊，那逻辑层就是对这些积⽊的搭建。数据访问层（DAL）：主要看数据层⾥⾯有没有包含逻辑处理，实际上它的各个函数主要完成各个对数据⽂件的操作。⽽不必管其他操作。在开发⼈员眼⾥，⼀个业务系统的分层只是技术架构上的，所以会把⽇志纪录、权限管理、数据库持久化、消息服务等等，把⼀些能分离出来的尽量分离出来，然后再把这些东西组合起来，就成了系统帮助层，它们贯彻于整个业务系统。三层架构是典型事务脚本逻辑结构，⼀个复杂的业务都在BBL⽅法体中从头到尾描述，处理⾼度复杂的业务显得⽆能为⼒估计所有的.NET 程序员都是从这个经典的三层的架构⼀步⼀步⾛过来的。三、DDD经典分层DDD：领域驱动设计TDD：是测试驱动开发

POEAA：企业应⽤架构模式DDD核⼼思想是由业务问题来控制解决⽅案的形式从以数据库为中⼼过渡到领域模型为中⼼

下⾯这个图是我在《领域驱动设计与模式实战》书中拍下来的，他完全诠释DDD的经典分层。各层概念：表现层（Presentation Layer）：图中的⽤户界⾯层包括⽤户接⼝层，⽤户输⼊和数据展⽰。应⽤层（Application Layer）：应⽤层定义系统的业务功能，并指挥领域层中的领域对象实现这些功能。领域层（Domain Layer）：核⼼层，实现所有业务逻辑。基础设施层（Infrastructure Layer）：提供整个业务系统的基础服务。各层在编译时的类依赖关系如下图（这是⼀个很矮矬穷的图）：⾼层模块不应该依赖于底层模块，两者都应该依赖于抽象抽象不应该依赖于细节，细节应该依赖于抽象。四、ABP分层上节FirstABP的解决⽅案：ABP详细分层：我们从上到下看看都是什么意思：表⽰层Presentation：View Models (Javascript)：=Views (HTML/CSS)：=Localization, Navigation, Notifications：多语⾔，菜单，通知web：Web API Controllers：webapi接⼝MVC Controllers, OData：OData是什么我也不知道应⽤层（Application）Application Services：应⽤服务DTOs：数据传输对象DTO Mappers：AutoMapper进⾏实体与DTO之间的映射Authorization：参数验证Session：Audit Logging：审计⽇志应⽤层提供⼀些应⽤服务（Application Services）⽅法供展现层调⽤。⼀个应⽤服务⽅法接收⼀个DTO(数据传输对象)作为输⼊参数，使⽤这个输⼊参数执⾏特定的领域层操作，并根据需要可返回另⼀个DTO。在展现层到领域层之间，不应该接收或返回实体(Entity)对象，应该进⾏DTO映射。⼀个应⽤服务⽅法通常被认为是⼀个⼯作单元（Unit of Work）。⽤户输⼊参数的验证⼯作也应该在应⽤层实现。ABP提供了⼀个基础架构让我们很容易地实现输⼊参数有效性验证。建议使⽤⼀种像AutoMapper这样的⼯具来进⾏实体与DTO之间的映射。领域层（Domain(Core)）Entities:实体，领域对象，代表业务领域的数据和操作value objects：实体模型Repositories：仓储，⽤来操作数据库进⾏数据存取。仓储接⼝在领域层定义，⽽仓储的实现类应该写在基础设施层。Domain Services：领域服务，当处理的业务规则跨越两个（及以上）实体时，应该写在领域服务⽅法⾥⾯。Domain Event：领域事件，在领域层某些特定情况发⽣时可以触发领域事件，并且在相应地⽅捕获并处理它们。Unit of Work：⼯作单元，⼀种设计模式，⽤于维护⼀个由已经被修改(如增加、删除和更新等)的业务对象组成的列表。它负责协调这些业务对象的持久化⼯作及并发问题。基础设施（Infrastructure）ORM (EntityFramework, NHibernate)：ORM框架，ABP提供了EF和NHibernate⽀持DB Migrations：EF Code First创建数据库⽤的Background Jobs：作业调度和⾃动任务，（类似）补充（单页⾯应⽤和多页⾯应⽤）在单页⾯应⽤中（SPA）,所有的资源都会⼀次性加载到客户端（或者只加载核⼼资源，懒加载其他资源），所有的后续和服务器的交互都是通过Ajax调⽤。Html代码是使⽤从服务端接收到的数据在客户端⽣成的。整个页⾯不会刷新，视图只是在必要时换⼊换出。有许多的Javascript SPA框架，⽐如AngularJs，DurandalJs,BackboneJs和EmberJs。ABP可以使⽤它们中的任何⼀个，但是提供了使⽤ AngularJs和DurandalJs的样例。在多页⾯（经典）应⽤中(MPA)，客户端向服务端发送请求，服务端代码（ MVC 控制器）从数据库中获取数据，然后Razor视图引擎⽣成html 代码。这些编译后的页⾯发回给客户端显⽰。每个新的页⾯都会导致完整页⾯的刷新。SPA和MPA涉及了完全不同的架构。对于后台管理系统来说，SPA是最好的候选者，另⼀⽅⾯，博客更适合MPA模型，因为博客渴望被搜索引擎抓取数据。虽然有很多⼯具可以使SPA对于搜索引擎可见，但是⽬前的⼀般做法就是使⽤MPA。最后ABP平衡了⼀些最好的框架或者类库，除此之外，ABP⾃⼰的类和系统也提供了⼀个很好的⽤于N层架构Web应⽤构建的基础设施，也提供了很轻松地创建分层的解决⽅案的模板，⽤作应⽤的起点。根据分层我们把项⽬的类库⽤解决⽅案的⽂件夹整理下：