领域建模的原则（战术篇）
如果团队和系统的规模不大，可以根据一两个人的经验设计出足够合适的模型。但是，当团队规模非常大、系统极其复杂的时，我们就需要制定一些原则来评审、检查各个各个团队产出的模型是否合适。
这些原则也许不能指导所有的场景，但是能在一定范围内做出约束。年轻的工程师总是喜欢自由，经过历练的工程师开始理解到约束的好处，想法也变得成熟。
这里我整理了一些 DDD 战术建模中的一些原则，作为软件领域建模中的基本要求。
1. 当一个【实体】被多个聚合根使用时，需要将其设计为【聚合根】或者将其拆开，不能再作为实体使用。
如果我们将聚合理解为系统中业务一致性、生命周期相对独立的一组实体，可以作为系统设计的基本单位，那么，一旦出现被多个聚合共享的实体，聚合就不再有意义了。
当两个聚合中出现了相同、相似的实体，有时候我们可能想要减少实体的数量，于是有了将其合并在一起的想法。比如，在分销系统中，销售和退货由两个不同模型实现，但是它们有类似的操作记录。如果将操作记录作为实体，但是处于不同的两个聚合，就会让这两个聚合耦合，让开发人员在开发时摸不着头脑。
类似的，在不同的业务场景中都会使用到附件，如果将附件作为实体存在，会造成混乱，与其这样不如直接设定一个原则，不允许出现共享实体的聚合。
2. 不允许使用【中间表】处理多对多关系，探明多对多原因，明确中间模型的归属。
多对多关系是领域建模的杀手，但在有些地方缺会是消除系统耦合的钥匙。
一个多空间系统，用户可以出现在不同的空间下，空间也可以容纳多个用户。看似是一个典型的多对多关系，我们大多数情况下会使用简单的中间表处理。
使用中间表往往意味着没有创建时间、状态等额外字段了。但是我们仔细一分析会发现，这个中间表的创建时间就是用户加入空间的时间，也就是说它是具有业务含义的，只不过被我们疏忽了。
当出现禁用空间下的用户业务时，只是删除中间表无法表达合适的业务需要，于是我们可以在中间表加上状态以满足业务需求。随着业务的丰满，中间模型就会显露出来，慢慢体现其重要意义。
多对多关系的存在，让我们无法建立合适的聚合。也就是说，无法将中间模型的归属问题明确下来。查询空间时，可以获得用户列表，同样的查询用户时，也可以获得空间列表。
那么，是用户拥有空间，还是空间拥有用户呢？
这就变得混沌，我们明确中间的模型为“成员”，明确空间拥有“成员”。当需要根据用户查询所属空间时，本质上是根据用户在空间下的成员信息来筛选空间。
当然，中间模型可能会归属到任何一边，这就需要架构师来拿捏和设计了，但是重要的是，中间模型的归属问题需要尽早的明确下来。
3. 区分【关联】和【拥有】，避免将本应该关联的模型设计到聚合之下，否则聚合非常大。
本条原则可以避免聚合设计过大，也可以避免不合适的生命周期。
以银行信用卡开户流程来说，代入到具体场景，银行账户是一个核心的模型，可以构成一个聚合。相关的，在开户时，会提交一个开户申请，银行的工作人员会对信息做出审核，完成审核后进行开户。
一个不佳的设计是，账户不能将开户申请纳入聚合中，因为申请的生命周期和账户并没有关系。开户申请和账户之间可以存在关联，但是不应该具有拥有关系。
4. 领域模型和数据库保持一致。
本条原则约束了领域模型落地实现的处理方式。
在理想的情况下，领域模型、数据库、API 都能体现系统状态（RESTful 叫做表征状态转移）的变化，如果能一一对应能让系统的复杂性降低，换个时髦的说法是让“熵”足够低。
有时候，我们会偷懒，想要将不同的模型持久化到同一张数据库表中，节省数据库设计。但是，这种差异造成了团队认知负载。如果没有必要，不建议这样操作。
5. 聚合的层级保持在 2 级，最多不超过 3 级。
这条原则非常好理解，层级过会带来落地上的巨大成本。
聚合的大小是领域模型设计中非常难取舍的地方。过大的聚合持久化，更新操作都不好处理；过小的聚合业务一致性得不到保证。
根据经验，2-3 层的聚合已经能满足大部分场景，如果超过 3 级，考虑将部分模型进行分解。
6. 事实数据快照化。
这条原则往往容易被初级的工程师忽略，但是非常重要。
根据范式理论，如果想做到很高的一致性，就不应该冗余过多的数据，这是大学数据库课程的基本内容。但是现实情况不能一概而论，对于重要的交易业务来说，完成业务后不会再更新，不存在一致性要求，反而是应该锁定交易时发生的关键数据。
这是因为一些事实数据本质上是业务合同。举个例子来说，合同的甲方乙方会记录下身份证号码、以及名字，即使当事人去派出所变更了姓名，也不会影响到合同中的主体。
7. 核心交易，设计交易流水或日志，用于审计。
接上一条原则，交易发生后，可能会对一些账户、库存、积分等信息进行变更，需要意识到为这些重要的信息记录流水、操作记录或者日志。
这是因为大部分信息系统都有商业契约性质，为了保护用户利益，需要在系统中留下足够的痕迹，避免未来“扯皮”，在纠纷发生时能提供证据。
8. 抽象类核心模型，提供拓展策略。
如果我们将一类相似的模型抽象统一后，注意设计良好的拓展策略，避免抽象后的模型无法支持拓展。
每位工程师都应该听过编程中追求复用的原则，但是并非所有的工程师认识到策复用和抽象带来的制约。当抽象发生时，意味着放弃了一些个性化的数据和行为，被抽象的模型在以后的命运中被绑定到一起。
如果我们想清楚了需要将一组抽象到一起，应该通过“不变点”找到共性，然后通过各种设计模式（例如，适配器模式，策略模式）为“变化点”提供拓展。
举个例子来说，餐饮领域中外卖、堂吃是两种不同的订单，外卖具有送货信息，堂吃具有座位信息。如果我们将两种订单抽象为一起，设计了订单模型，这是合理的，因为订单是“不变点”，和金额、结账、支付有关。
对于送货信息、座位信息可以使用适配器模式隔离出来作为独立的聚合并关联订单，避免订单上挂载送货信息、座位信息这类和场景相关的信息。
9. 当业务变化时，分而治之；当业务稳定后，抽象统一。
接上一条原则，如果在是否将相似模型抽象到一起而犹豫时，说明没有足够的信息输入，以至于缺乏信心。
抽象的模型是通过归纳产生的，如果没有信息做出归纳，可以优先分而治之，待业务明确后再重构为统一的方式。
10. 让合适的人做合适的决策，并做好决策记录，为后续决策提供背景信息。
最后一条是写给架构师的原则。
如果一个团队存在专门的架构师，而且团队又非常庞大时，架构师无法获得完整、足够细致的信息，需要承认无法在任何场景下做出合理的决策。
架构师应该只关注系统核心的模型，以及划定上下文边界附近的模型归属，确保系统作为一个有机的整体。而对于系统某个角落的模型设计应该交给具体的开发人员来决定，记得做好决策记录就行。
因为架构师认识到什么重要，什么不重要比事无巨细的决策更有意义。