DDD随便整理

一、DP

Domain Primitive：Domain Primitive是一个在特定领域里，拥有精准定义的、可自我验证的、拥有行为的Value Object。

• DP是一个传统意义上的Value Object，拥有Immutable的特性
• DP是一个完整的概念整体，拥有精准定义
• DP使用业务域中的原生语言
• DP可以是业务域的最小组成部分、也可以构建复杂组合

在DDD里，DP可以说是一切模型、方法、架构的基础，而就像Integer、String一样，DP又是无所不在的。可以带来的好处：

• 接口的清晰度（可阅读性）
• 数据验证和错误处理
• 业务逻辑代码的清晰度
• 可测试性

※从一些入参里抽取一部分数据，然后调用一个外部依赖获取更多的数据，然后通常从新的数据中再抽取部分数据用作其他的作用。这种代码通常被称作“胶水代码”。

使用Domain Primitive的三原则

• 让隐性的概念显性化
• 让隐性的上下文显性化
• 封装多对象行为

常见的DP的使用场景包括：

• 有格式限制的String：比如Name，PhoneNumber，OrderNumber，ZipCode，Address等
• 有限制的Integer：比如OrderId（>0），Percentage（0-100%），Quantity（>=0）等
• 可枚举的int：比如Status（一般不用Enum因为反序列化问题）
• Double或BigDecimal：一般用到的Double或BigDecimal都是有业务含义的，比如Temperature、Money、Amount、ExchangeRate、Rating等
• 复杂的数据结构：比如Map<String, List<Integer>>等，尽量能把Map的所有操作包装掉，仅暴露必要行为

二、应用架构

在做架构设计时，一个好的架构应该需要实现以下几个目标：

• 独立于框架：架构不应该依赖某个外部的库或框架，不应该被框架的结构所束缚。
• 独立于UI：前台展示的样式可能会随时发生变化（今天可能是网页、明天可能变成console、后天是独立app），但是底层架构不应该随之而变化。
• 独立于底层数据源：无论今天你用MySQL、Oracle还是MongoDB、CouchDB，甚至使用文件系统，软件架构不应该因为不同的底层数据储存方式而产生巨大改变。
• 独立于外部依赖：无论外部依赖如何变更、升级，业务的核心逻辑不应该随之而大幅变化。
• 可测试：无论外部依赖了什么数据库、硬件、UI或者服务，业务的逻辑应该都能够快速被验证正确性。

Transaction Script（事务脚本）有以下几个很大的问题

问题1-可维护性能差：可维护性 = 当依赖变化时，有多少代码需要随之改变

• 数据结构的不稳定性：AccountDO类是一个纯数据结构，映射了数据库中的一个表。这里的问题是数据库的表结构和设计是应用的外部依赖，长远来看都有可能会改变，比如数据库要做Sharding，或者换一个表设计，或者改变字段名。
• 依赖库的升级：AccountMapper依赖MyBatis的实现，如果MyBatis未来升级版本，可能会造成用法的不同（可以参考iBatis升级到基于注解的MyBatis的迁移成本）。同样的，如果未来换一个ORM体系，迁移成本也是巨大的。
• 第三方服务依赖的不确定性：第三方服务，比如Yahoo的汇率服务未来很有可能会有变化：轻则API签名变化，重则服务不可用需要寻找其他可替代的服务。在这些情况下改造和迁移成本都是巨大的。同时，外部依赖的兜底、限流、熔断等方案都需要随之改变。
• 第三方服务API的接口变化：YahooForexService.getExchangeRate返回的结果是小数点还是百分比？入参是（source, target）还是（target, source）？谁能保证未来接口不会改变？如果改变了，核心的金额计算逻辑必须跟着改，否则会造成资损。
• 中间件更换：今天我们用Kafka发消息，明天如果要上阿里云用RocketMQ该怎么办？后天如果消息的序列化方式从String改为Binary该怎么办？如果需要消息分片该怎么改？

问题2-可拓展性差：可扩展性 = 做新需求或改逻辑时，需要新增/修改多少代码

• 数据来源被固定、数据格式不兼容：原有的AccountDO是从本地获取的，而跨行转账的数据可能需要从一个第三方服务获取，而服务之间数据格式不太可能是兼容的，导致从数据校验、数据读写、到异常处理、金额计算等逻辑都要重写。
• 业务逻辑无法复用：数据格式不兼容的问题会导致核心业务逻辑无法复用。每个用例都是特殊逻辑的后果是最终会造成大量的if-else语句，而这种分支多的逻辑会让分析代码非常困难，容易错过边界情况，造成bug。
• 逻辑和数据存储的相互依赖：当业务逻辑增加变得越来越复杂时，新加入的逻辑很有可能需要对数据库schema或消息格式做变更。而变更了数据格式后会导致原有的其他逻辑需要一起跟着动。在最极端的场景下，一个新功能的增加会导致所有原有功能的重构，成本巨大。

问题3-可测试性能差：可测试性 = 运行每个测试用例所花费的时间 * 每个需求所需要增加的测试用例数量

• 设施搭建困难：当代码中强依赖了数据库、第三方服务、中间件等外部依赖之后，想要完整跑通一个测试用例需要确保所有依赖都能跑起来，这个在项目早期是及其困难的。在项目后期也会由于各种系统的不稳定性而导致测试无法通过。
• 运行耗时长：大多数的外部依赖调用都是I/O密集型，如跨网络调用、磁盘调用等，而这种I/O调用在测试时需要耗时很久。另一个经常依赖的是笨重的框架如Spring，启动Spring容器通常需要很久。当一个测试用例需要花超过10秒钟才能跑通时，绝大部分开发都不会很频繁的测试。
• 耦合度高：假如一段脚本中有A、B、C三个子步骤，而每个步骤有N个可能的状态，当多个子步骤耦合度高时，为了完整覆盖所有用例，最多需要有N * N * N个测试用例。当耦合的子步骤越多时，需要的测试用例呈指数级增长。

总结分析

• 单一性原则（Single Responsibility Principle）：单一性原则要求一个对象/类应该只有一个变更的原因。但是在这个案例里，代码可能会因为任意一个外部依赖或计算逻辑的改变而改变。
• 依赖反转原则（Dependency Inversion Principle）：依赖反转原则要求在代码中依赖抽象，而不是具体的实现。在这个案例里外部依赖都是具体的实现，比如YahooForexService虽然是一个接口类，但是它对应的是依赖了Yahoo提供的具体服务，所以也算是依赖了实现。同样的KafkaTemplate、MyBatis的DAO实现都属于具体实现。
• 开放封闭原则（Open Closed Principle）：开放封闭原则指开放扩展，但是封闭修改。在这个案例里的金额计算属于可能会被修改的代码，这个时候该逻辑应该需要被包装成为不可修改的计算类，新功能通过计算类的拓展实现。

Account实体类和AccountDO数据类的对比如下：

• Data Object数据类：AccountDO是单纯的和数据库表的映射关系，每个字段对应数据库表的一个column，这种对象叫Data Object。DO只有数据，没有行为。AccountDO的作用是对数据库做快速映射，避免直接在代码里写SQL。无论你用的是MyBatis还是Hibernate这种ORM，从数据库来的都应该先直接映射到DO上，但是代码里应该完全避免直接操作DO。
• Entity实体类：Account是基于领域逻辑的实体类，它的字段和数据库储存不需要有必然的联系。Entity包含数据，同时也应该包含行为。在Account里，字段也不仅仅是String等基础类型，而应该尽可能用上一讲的Domain Primitive代替，可以避免大量的校验代码。

DAO和Repository类的对比如下：

• DAO对应的是一个特定的数据库类型的操作，相当于SQL的封装。所有操作的对象都是DO类，所有接口都可以根据数据库实现的不同而改变。比如，insert和update属于数据库专属的操作。
• Repository对应的是Entity对象读取储存的抽象，在接口层面做统一，不关注底层实现。比如，通过save保存一个Entity对象，但至于具体是insert还是update并不关心。Repository的具体实现类通过调用DAO来实现各种操作，通过Builder/Factory对象实现AccountDO到Account之间的转化。

Repository和Entity：

• 通过Account对象，避免了其他业务逻辑代码和数据库的直接耦合，避免了当数据库字段变化时，大量业务逻辑也跟着变的问题。
• 通过Repository，改变业务代码的思维方式，让业务逻辑不再面向数据库编程，而是面向领域模型编程。
• Account属于一个完整的内存中对象，可以比较容易的做完整的测试覆盖，包含其行为。
• Repository作为一个接口类，可以比较容易的实现Mock或Stub，可以很容易测试。
• AccountRepositoryImpl实现类，由于其职责被单一出来，只需要关注Account到AccountDO的映射关系和Repository方法到DAO方法之间的映射关系，相对于来说更容易测试。

防腐层（ACL）

这种常见的设计模式叫做Anti-Corruption Layer（防腐层或ACL）。很多时候我们的系统会去依赖其他的系统，而被依赖的系统可能包含不合理的数据结构、API、协议或技术实现，如果对外部系统强依赖，会导致我们的系统被”腐蚀“。这个时候，通过在系统间加入一个防腐层，能够有效的隔离外部依赖和内部逻辑，无论外部如何变更，内部代码可以尽可能的保持不变。

ACL不仅仅只是多了一层调用，在实际开发中ACL能够提供更多强大的功能：

• 适配器：很多时候外部依赖的数据、接口和协议并不符合内部规范，通过适配器模式，可以将数据转化逻辑封装到ACL内部，降低对业务代码的侵入。在这个案例里，我们通过封装了ExchangeRate和Currency对象，转化了对方的入参和出参，让入参出参更符合我们的标准。
• 缓存：对于频繁调用且数据变更不频繁的外部依赖，通过在ACL里嵌入缓存逻辑，能够有效的降低对于外部依赖的请求压力。同时，很多时候缓存逻辑是写在业务代码里的，通过将缓存逻辑嵌入ACL，能够降低业务代码的复杂度。
• 兜底：如果外部依赖的稳定性较差，一个能够有效提升我们系统稳定性的策略是通过ACL起到兜底的作用，比如当外部依赖出问题后，返回最近一次成功的缓存或业务兜底数据。这种兜底逻辑一般都比较复杂，如果散落在核心业务代码中会很难维护，通过集中在ACL中，更加容易被测试和修改。
• 易于测试：类似于之前的Repository，ACL的接口类能够很容易的实现Mock或Stub，以便于单元测试。
• 功能开关：有些时候我们希望能在某些场景下开放或关闭某个接口的功能，或者让某个接口返回一个特定的值，我们可以在ACL配置功能开关来实现，而不会对真实业务代码造成影响。同时，使用功能开关也能让我们容易的实现Monkey测试，而不需要真正物理性的关闭外部依赖。

改造开发步骤

• 用Domain Primitive封装跟实体无关的无状态计算逻辑
• 用Entity封装单对象的有状态的行为，包括业务校验
• 用Domain Service封装多对象逻辑
• 仅包含Orchestration（编排）的服务叫做Application Service（应用服务）

代码组织结构

• Types模块：Types模块是保存可以对外暴露的Domain Primitives的地方。Domain Primitives因为是无状态的逻辑，可以对外暴露，所以经常被包含在对外的API接口中，需要单独成为模块。Types模块不依赖任何类库，纯POJO。
• Domain模块：Domain模块是核心业务逻辑的集中地，包含有状态的Entity、领域服务Domain Service、以及各种外部依赖的接口类（如Repository、ACL、中间件等。Domain模块仅依赖Types模块，也是纯POJO。
• Application模块：Application模块主要包含Application Service和一些相关的类。Application模块依赖Domain模块。还是不依赖任何框架，纯POJO。
• Infrastructure模块：Infrastructure模块包含了Persistence、Messaging、External等模块。比如：Persistence模块包含数据库DAO的实现，包含Data Object、ORM Mapper、Entity到DO的转化类等。Persistence模块要依赖具体的ORM类库，比如MyBatis。如果需要用Spring-Mybatis提供的注解方案，则需要依赖Spring。
• Web模块：Web模块包含Controller等相关代码。如果用SpringMVC则需要依赖Spring。
• Start模块：Start模块是SpringBoot的启动类。

三、Repository模式

贫血模型的特征

1. 有大量的XxxDO对象：这里DO虽然有时候代表了Domain Object，但实际上仅仅是数据库表结构的映射，里面没有包含（或包含了很少的）业务逻辑；
2. 服务和Controller里有大量的业务逻辑：比如校验逻辑、计算逻辑、格式转化逻辑、对象关系逻辑、数据存储逻辑等；
3. 大量的Utils工具类等。

贫血模型的缺陷

1. 无法保护模型对象的完整性和一致性：因为对象的所有属性都是公开的，只能由调用方来维护模型的一致性，而这个是没有保障的；之前曾经出现的案例就是调用方没有能维护模型数据的一致性，导致脏数据使用时出现bug，这一类的bug还特别隐蔽，很难排查到。
2. 对象操作的可发现性极差：单纯从对象的属性上很难看出来都有哪些业务逻辑，什么时候可以被调用，以及可以赋值的边界是什么；比如说，Long类型的值是否可以是0或者负数？
3. 代码逻辑重复：比如校验逻辑、计算逻辑，都很容易出现在多个服务、多个代码块里，提升维护成本和bug出现的概率；一类常见的bug就是当贫血模型变更后，校验逻辑由于出现在多个地方，没有能跟着变，导致校验失败或失效。
4. 代码的健壮性差：比如一个数据模型的变化可能导致从上到下的所有代码的变更。
5. 强依赖底层实现：业务代码里强依赖了底层数据库、网络/中间件协议、第三方服务等，造成核心逻辑代码的僵化且维护成本高。

硬件（Hardware）：指创造了之后不可（或者很难）变更的东西。数据库对于开发来说，就属于”硬件“，数据库选型后基本上后面不会再变，比如：用了MySQL就很难再改为MongoDB，改造成本过高。

软件（Software）：指创造了之后可以随时修改的东西。对于开发来说，业务代码应该追求做”软件“，因为业务流程、规则在不停的变化，我们的代码也应该能随时变化。

固件（Firmware）：即那些强烈依赖了硬件的软件。我们常见的是路由器里的固件或安卓的固件等等。固件的特点是对硬件做了抽象，但仅能适配某款硬件，不能通用。所以今天不存在所谓的通用安卓固件，而是每个手机都需要有自己的固件。

从上面的描述我们能看出来，数据库在本质上属于”硬件“，DAO在本质上属于”固件“，而我们自己的代码希望是属于”软件“。但是，固件有个非常不好的特性，那就是会传播，也就是说当一个软件强依赖了固件时，由于固件的限制，会导致软件也变得难以变更，最终让软件变得跟固件一样难以变更。

对象类型

• Data Object（DO、数据对象）：实际上是我们在日常工作中最常见的数据模型。但是在DDD的规范里，DO应该仅仅作为数据库物理表格的映射，不能参与到业务逻辑中。为了简单明了，DO的字段类型和名称应该和数据库物理表格的字段类型和名称一一对应，这样我们不需要去跑到数据库上去查一个字段的类型和名称。（当然，实际上也没必要一摸一样，只要你在Mapper那一层做到字段映射）
• Entity（实体对象）：实体对象是我们正常业务应该用的业务模型，它的字段和方法应该和业务语言保持一致，和持久化方式无关。也就是说，Entity和DO很可能有着完全不一样的字段命名和字段类型，甚至嵌套关系。Entity的生命周期应该仅存在于内存中，不需要可序列化和可持久化。
• DTO（传输对象）：主要作为Application层的入参和出参，比如CQRS里的Command、Query、Event，以及Request、Response等都属于DTO的范畴。DTO的价值在于适配不同的业务场景的入参和出参，避免让业务对象变成一个万能大对象。

转换器

• DTO Assembler：在Application层，Entity到DTO的转化器有一个标准的名称叫DTO Assembler。Martin Fowler在P of EAA一书里对于DTO和Assembler的描述：Data Transfer Object。DTO Assembler的核心作用就是将1个或多个相关联的Entity转化为1个或多个DTO。
• Data Converter：在Infrastructure层，Entity到DO的转化器没有一个标准名称，但是为了区分Data Mapper，我们叫这种转化器Data Converter。这里要注意Data Mapper通常情况下指的是DAO，比如Mybatis的Mapper。Data Mapper的出处也在P of EAA一书里：Data Mapper。

模型规范总结

	DO	Entity	DTO
目的	数据库表映射	业务逻辑	适配业务场景
代码层级	Infrastructure	Domain	Application
命名规范	XxxDO	Xxx	XxxDTO XxxCommand XxxRequest等
字段名称标准	数据库表字段名	业务语言	和调用方商定
字段数据类型	数据库字段类型	尽量是有业务含义的类型，比如DP	和调用方商定
是否需要序列化	不需要	不需要	需要
转化器	Data Converter	Data Converter DTO Assembler	DTO Assembler

Repository代码规范

1. 接口名称不应该使用底层实现的语法：我们常见的insert、select、update、delete都属于SQL语法，使用这几个词相当于和DB底层实现做了绑定。相反，我们应该把Repository当成一个中性的类似Collection的接口，使用语法如find、save、remove。在这里特别需要指出的是区分insert/add和update本身也是一种和底层强绑定的逻辑，一些储存如缓存实际上不存在insert和update的差异，在这个case里，使用中性的save接口，然后在具体实现上根据情况调用DAO的insert或update接口。
2. 出参入参不应该使用底层数据格式：需要记得的是Repository操作的是Entity对象（实际上应该是Aggregate Root），而不应该直接操作底层的DO。更近一步，Repository接口实际上应该存在于Domain层，根本看不到DO的实现。这个也是为了避免底层实现逻辑渗透到业务代码中的强保障。
3. 应该避免所谓的“通用”Repository模式：很多ORM框架都提供一个“通用”的Repository接口，然后框架通过注解自动实现接口，比较典型的例子是Spring Data、Entity Framework等，这种框架的好处是在简单场景下很容易通过配置实现，但是坏处是基本上无扩展的可能性（比如加定制缓存逻辑），在未来有可能还是会被推翻重做。

四、领域层设计规范

实体类（Entity）

• 创建即一致：constructor参数要包含所有必要属性，或者在constructor里有合理的默认值。使用Factory模式来降低调用方复杂度
• 尽量避免public setter
• 通过聚合根保证主子实体的一致性
• 不可以强依赖其他聚合根实体或领域服务
• 任何实体的行为只能直接影响到本实体（和其子实体）

领域服务（Domain Service）

• 单对象策略型
• 跨对象事务型
• 通用组件型

策略对象（Domain Policy）

• Policy或者Strategy设计模式是一个通用的设计模式，但是在DDD架构中会经常出现，其核心就是封装领域规则。

领域事件

• 领域事件是一个在领域里发生了某些事后，希望领域里其他对象能够感知到的通知机制。

五、聊聊如何避免写流水账代码

通过不同的代码分层和规范，拆分出逻辑清晰，职责明确的分层和模块，也便于一些通用能力的沉淀。

主要的几个步骤分为：

1. 分离出独立的Interface接口层，负责处理网络协议相关的逻辑
2. 从真实业务场景中，找出具体用例（Use Cases），然后将具体用例通过专用的Command指令、Query查询、和Event事件对象来承接
3. 分离出独立的Application应用层，负责业务流程的编排，响应Command、Query和Event。每个应用层的方法应该代表整个业务流程中的一个节点
4. 处理一些跨层的横切关注点，如鉴权、异常处理、校验、缓存、日志等

Interface接口层：作为所有对外的门户，将网络协议和业务逻辑解耦。

• HTTP框架：如Spring MVC框架，Spring Cloud等
• RPC框架：如Dubbo、HSF、gRPC等
• 消息队列MQ的“消费者”：比如JMS的onMessage，RocketMQ的MessageListener等
• Socket通信：Socket通信的receive、WebSocket的onMessage等
• 文件系统：WatcherService等
• 分布式任务调度：SchedulerX等

规范：Interface层的HTTP和RPC接口，返回值为Result，捕捉所有异常。

规范：Application层的所有接口返回值为DTO，不负责处理异常。

规范：一个Interface层的类应该是“小而美”的，应该是面向“一个单一的业务”或“一类同样需求的业务”，需要尽量避免用同一个类承接不同类型业务的需求。

Application层的几个核心类：

• ApplicationService应用服务：最核心的类，负责业务流程的编排，但本身不负责任何业务逻辑
• DTO Assembler：负责将内部领域模型转化为可对外的DTO
• Command、Query、Event对象：作为ApplicationService的入参
• 返回的DTO：作为ApplicationService的出参

Command、Query、Event对象：

• Command指令：指调用方明确想让系统操作的指令，其预期是对一个系统有影响，也就是写操作。通常来讲指令需要有一个明确的返回值（如同步的操作结果，或异步的指令已经被接受）。
• Query查询：指调用方明确想查询的东西，包括查询参数、过滤、分页等条件，其预期是对一个系统的数据完全不影响的，也就是只读操作。
• Event事件：指一件已经发生过的既有事实，需要系统根据这个事实作出改变或者响应的，通常事件处理都会有一定的写操作。事件处理器不会有返回值。这里需要注意一下的是，Application层的Event概念和Domain层的DomainEvent是类似的概念，但不一定是同一回事，这里的Event更多是外部一种通知机制而已。

简单总结下：

	Command	Query	Event
语意	”希望“能触发的操作	各种条件的查询	已经发生过的事情
读/写	写	只读	通常是写
返回值	DTO或Boolean	DTO或Collection	Void

规范：ApplicationService的接口入参只能是一个Command、Query或Event对象，CQE对象需要能代表当前方法的语意。唯一可以的例外是根据单一ID查询的情况，可以省略掉一个Query对象的创建。

• CQE：CQE对象是ApplicationService的输入，是有明确的”意图“的，所以这个对象必须保证其”正确性“。

• DTO：DTO对象只是数据容器，只是为了和外部交互，所以本身不包含任何逻辑，只是贫血对象。

规范：CQE对象的校验应该前置，避免在ApplicationService里做参数的校验。可以通过JSR303/380和Spring Validation来实现。

规范：针对于不同语意的指令，要避免CQE对象的复用。

• Application Service是业务流程的封装，不处理业务逻辑
• ApplicationService应该永远返回DTO而不是Entity
• Application层只返回DTO，可以直接抛异常，不用统一处理。所有调用到的服务也都可以直接抛异常，除非需要特殊处理，否则不需要刻意捕捉异常

ACL防腐层的简单原理如下：

• 对于依赖的外部对象，我们抽取出所需要的字段，生成一个内部所需的VO或DTO类

• 构建一个新的Facade，在Facade中封装调用链路，将外部类转化为内部类

• 针对外部系统调用，同样的用Facade方法封装外部调用链路

Interface层

职责：主要负责承接网络协议的转化、Session管理等。

• 接口数量：避免所谓的统一API，不必人为限制接口类的数量，每个/每类业务对应一套接口即可，接口参数应该符合业务需求，避免大而全的入参。
• 接口出参：统一返回Result。
• 异常处理：应该捕捉所有异常，避免异常信息的泄漏。可以通过AOP统一处理，避免代码里有大量重复代码。

Application层：

• 入参：具像化Command、Query、Event对象作为ApplicationService的入参，唯一可以的例外是单ID查询的场景。
• CQE的语意化：CQE对象有语意，不同用例之间语意不同，即使参数一样也要避免复用。
• 入参校验：基础校验通过Bean Validation api解决。Spring Validation自带Validation的AOP，也可以自己写AOP。
• 出参：统一返回DTO，而不是Entity或DO。
• DTO转化：用DTO Assembler负责Entity/VO到DTO的转化。
• 异常处理：不统一捕捉异常，可以随意抛异常。

部分Infra层：

• 用ACL防腐层将外部依赖转化为内部代码，隔离外部的影响。

业务流程设计模式：

• 没有最好的模式，取决于业务场景、依赖关系、以及是否有业务“负责人”。避免拿着锤子找钉子。

六、美团

1、软件系统复杂性应对

解决复杂和大规模软件的武器可以被粗略地归为三类：抽象、分治和知识。

分治 把问题空间分割为规模更小且易于处理的若干子问题。分割后的问题需要足够小，以便一个人单枪匹马就能够解决他们；其次，必须考虑如何将分割后的各个部分装配为整体。分割得越合理越易于理解，在装配成整体时，所需跟踪的细节也就越少。即更容易设计各部分的协作方式。评判什么是分治得好，即高内聚低耦合。

抽象 使用抽象能够精简问题空间，而且问题越小越容易理解。举个例子，从北京到上海出差，可以先理解为使用交通工具前往，但不需要一开始就想清楚到底是高铁还是飞机，以及乘坐他们需要注意什么。

知识 顾名思义，DDD可以认为是知识的一种。

DDD提供了这样的知识手段，让我们知道如何抽象出限界上下文以及如何去分治。

• 业务架构——根据业务需求设计业务模块及其关系
• 系统架构——设计系统和子系统的模块
• 技术架构——决定采用的技术及框架

DDD的核心诉求就是将业务架构映射到系统架构上，在响应业务变化调整业务架构时，也随之变化系统架构。而微服务追求业务层面的复用，设计出来的系统架构和业务一致；在技术架构上则系统模块之间充分解耦，可以自由地选择合适的技术架构，去中心化地治理技术和数据。

2、设计领域模型的一般步骤如下：

1. 根据需求划分出初步的领域和限界上下文，以及上下文之间的关系；
2. 进一步分析每个上下文内部，识别出哪些是实体，哪些是值对象；
3. 对实体、值对象进行关联和聚合，划分出聚合的范畴和聚合根；
4. 为聚合根设计仓储，并思考实体或值对象的创建方式；
5. 在工程中实践领域模型，并在实践中检验模型的合理性，倒推模型中不足的地方并重构。

3、战略设计侧重于高层次、宏观上去划分和集成限界上下文，而战术设计则关注更具体使用建模工具来细化上下文。

• 限界上下文：一个由显示边界限定的特定职责。领域模型便存在于这个边界之内。在边界内，每一个模型概念，包括它的属性和操作，都具有特殊的含义。
• 实体：当一个对象由其标识（而不是属性）区分时，这种对象称为实体（Entity）。
• 值对象：当一个对象用于对事务进行描述而没有唯一标识时，它被称作值对象（Value Object）。
• 聚合根：Aggregate(聚合）是一组相关对象的集合，作为一个整体被外界访问，聚合根（Aggregate Root）是这个聚合的根节点。
• 领域服务：一些重要的领域行为或操作，可以归类为领域服务。它既不是实体，也不是值对象的范畴。
• 领域事件：领域事件是对领域内发生的活动进行的建模。

4、代码组织

资源库（Repository）的作用，就是对领域的存储和访问进行统一管理的对象。资源库对外的整体访问由Repository提供，它聚合了各个资源库的数据信息，同时也承担了资源存储的逻辑（例如缓存更新机制等）。

有以下几种情况会考虑引入防腐层：

• 需要将外部上下文中的模型翻译成本上下文理解的模型。
• 不同上下文之间的团队协作关系，如果是供奉者关系，建议引入防腐层，避免外部上下文变化对本上下文的侵蚀。
• 该访问本上下文使用广泛，为了避免改动影响范围过大。

七、各层对象

DTO：Data Transfer Object，数据传输对象。

DO：Domain Object，领域对象。（Database Object，数据库对象）

PO：Persistent Object，持久层对象。

VO：Value Object，值对象。（View Object，视图对象）

Query：查询对象。

Command：涉及更新操作对象。

Event：事件对象。

POJO：Plain Ordinary Java Object，简单的 Java 对象。