这篇文章行文结构对照微软博客, 结合本人意译和多年实践的回顾思考形成此次读书笔记。
领域-驱动-设计(DDD)提倡 基于(用例相关的现实业务)进行建模
。
现实问题视为领域 独立的问题描述为有界限的上下文
许多技术概念和模式,例如充血模型(对应我们常写贫血模型)、值对象、聚合和聚合根规则。
有时DDD技术规则和模式被视为障碍/啰嗦,对于实施DDD方法而言,学习曲线比较陡峭。
不要为了实施而实施,最重要的是 使用通用语言编写与业务问题一致的领域代码 。
此外仅当您要实现具有复杂业务规则的微服务时,才应使用DDD方法,诸如CRUD服务之类的简单职责可以通过更简单的方法进行管理。
DDD模式可以协助 划分微服务边界
在已经确定的界限上下文,您可以为领域建模:实体模型、值对象和聚合,DDD与边界有关,微服务也与边界有关。
划分界限上下文,要平衡两个目标:
这两个目标可能彼此矛盾,两者通过演进的方式达到平衡:
尽可能分解系统,直到在下次分解时感到服务通信迅速增加。
例如从数据库中加载的实体,有时候需要做一下修正(截取部分信息、增加信息)才能适配客户端UI。
订单DDD微服务有三层:
三层形成的类库 有清晰且明确的依赖关系
负责表达业务概念、业务场景和业务规则。这一层会将技术细节传递到基础设施层,这一层控制、反映业务场景,是业务软件的核心。
领域模型层是表达业务的地方,在编程上体现为 捕获数据和行为(具有逻辑方法)的领域实体的类库
遵循 持久性无感知和基础设施无感知
原则
领域模型层必须完全忽略数据持久性细节,这些持久性任务应由基础设施层执行,因此,此层不应直接依赖基础设施,这意味着一个重要规则是领域模型实体类应为POCO。
领域实体不应直接依赖于任何数据访问基础框架(EF、NHibernate),理想情况下,您的域实体不应继承自或实现任何基础设施中定义的任何类型。 大多数现代的ORM框架(例如Entity Framework Core)都支持这种方法,因此您的领域模型不会与基础设施耦合。
持久性无感知
原则很重要,但也不应忽略持久性问题 理解物理数据模型以及它如何映射到您的实体对象模型仍然非常重要,否则你的设计将会是空中楼阁。而且,大多数时候你将本应该采用关系数据库的设计直接迁移到 NoSQL或面向文档的数据库,领域模型层很可能不适用(基于存储技术和ORM技术,您的实体模型仍然必须遵守一些约束条件)。
定义软件要执行的工作,并引导(可表达的领域对象)解决问题。
该层对对业务负责,有时会与其他系统的应用程序层交互。
该层 保持薄
: 它不包含业务规则或知识,而仅协调任务并将工作委托给下一层的域对象协作;
它没有反映业务情况的状态,但是可以具有反映用户或程序的任务进度的状态。
微服务的应用层在.NET中一般表现为WebAPI,webapi实现交互、远程网络连接、为UI/Client app提供的外部请求中转。
再次强调webapi不应该包含业务规则或领域知识(尤其是用于事务或更新的领域规则),这些应归领域模型类库所有。
应用层只能协调任务,不能保存或定义任何域状态(域模型),它将业务规则的执行委托给领域模型类本身(聚合根和域实体),这将最终更新这些域实体中的数据。
总体来看,应用层是为实现前端用例的地方。
基础设施层: 定义如何将最初保存在领域实体中的数据持久化到数据库或者其他存储结构的过程。
一个示例是使用Entity Framework Core代码实现存储库模式类: 该存储库模式类使用DBContext将数据持久存储在关系数据库中。
根据前面提到的 持久化无感知
和 基础设施无感知
原则,基础设施层不得“污染”领域模型层。
再次强调:必须保持领域层实体对基础设施层框架的无感知状态, 领域模型层类库应该只包含领域代码,而只有POCO实体类可以实现软件的核心,并且与基础设施技术完全脱钩。
翻译自: https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/ddd-oriented-microservice