[半翻] 设计面向DDD的微服务

这篇文章行文结构对照微软博客，结合本人意译和多年实践的回顾性思考形成此次读书笔记。

Domian-driven Design

领域-驱动-设计（DDD）提倡基于(用例相关的现实业务)进行建模。

1. DDD的视角

DDD将现实问题视为领域;
DDD将独立的问题描述为有界限的上下文(一个有界上下文对应一个微服务)，并强调通用语言讨论这些问题

2. DDD提出的概念

许多技术概念和模式，例如充血模型(对应我们常写贫血模型)、值对象、聚合和聚合根规则。

3. 目前实施DDD的现状

有时DDD技术规则和模式被视为障碍/啰嗦，对于实施DDD方法而言，学习曲线比较陡峭。
不要为了实施而实施，最重要的是使用通用语言编写与业务问题一致的领域代码。

此外仅当您要实现具有复杂业务规则的微服务时，才应使用DDD方法，诸如CRUD服务之类的简单职责可以通过更简单的方法进行管理。

DDD模式可以协助划分微服务边界
在已经确定的界限上下文，您可以为领域建模：实体模型、值对象和聚合，DDD与边界有关，微服务也与边界有关。

尽量保持小型微服务

划分界限上下文，要平衡两个目标：

创建尽可能小的微服务（这一点不应该成为主要动力)
要避免微服务之间过密的通信

这两个目标可能彼此矛盾，两者通过演进的方式达到平衡：
尽可能分解系统，直到在下次分解时感到服务通信迅速增加。

DDD微服务中的层

DDD定义的多层是为了管控代码的复杂性，这些层是逻辑组件(类似环环相扣的齿轮)。
不同的层（例如领域模型层与表示层等）可能具有不同的类型，此时层间类型需要转换。

例如从数据库中加载的实体，有时候需要做一下修正(截取部分信息、增加信息)才能适配客户端UI。

领域模型层中的领域实体不应传播到它不属于的其他区域(如表示层)
重要的是有一个由聚合根控制的域模型，以确保与该实体组（聚合）相关的所有不变式和规则都是通过单个入口点或（聚合根）执行。

订单DDD微服务有三层：

应用程序层 Ordering.API
领域层 Ordering.Domain
基础设施层 Ordering.Infrastructure

三层形成的类库有清晰且明确的依赖关系

1. The domain model layer

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

领域模型层是表达业务的地方，在编程上体现为捕获数据和行为（具有逻辑方法）的领域实体的类库
遵循持久性无感知和基础设施无感知原则

领域模型层必须完全忽略数据持久性细节，这些持久性任务应由基础设施层执行，因此，此层不应直接依赖基础设施，这意味着一个重要规则是领域模型实体类应为POCO。
领域实体不应直接依赖于任何数据访问基础框架（EF、NHibernate），理想情况下，您的域实体不应继承自或实现任何基础设施中定义的任何类型。大多数现代的ORM框架（例如Entity Framework Core）都支持这种方法，因此您的领域模型不会与基础设施耦合。

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

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

2. Application Layer

定义软件要执行的工作，并引导（充血的领域对象）解决问题。
该层对对业务负责，有时会与其他系统的应用程序层交互。
该层保持薄：它不包含业务规则或知识，而仅协调任务并将工作委托给下一层的域对象协作;
它没有反映业务情况的状态，但是可以具有反映用户或程序的任务进度的状态。

微服务的应用层在.NET中一般表现为WebAPI，webapi实现交互、远程网络连接、为UI/Client app提供的外部请求中转。再次强调webapi不应该包含业务规则或领域知识（尤其是用于事务或更新的领域规则），这些应归领域模型类库所有。
应用层只协调任务，不能保存或定义任何域状态（域模型），它将业务规则的执行委托给领域模型类本身（聚合根和领域实体），这将最终更新这些领域实体中的数据。

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