领域关系模型
领域模型的应用
现在的领域模型中，各自领域划分是一件需要不停假设，不断推翻假设，最后产出一个领域模型的过程。
领域模型本质是一个领域实体对象，在表达领域与领域之间的交互时，用到了聚合对象和边界上下文来解决领域之间的关系连接。在概念上，理解成本高，实现边界模糊。进而在系统实现上，模糊的边界是代码腐烂的发源地。有没有一种更好的方式可以即降低了理解成本，又能在系统层面上实现更简单，这就引出本文的观点，领域模型之外的一个补充或替代方案，关系模型。
为什么引入关系，得先从逻辑说起。
芝本秀德在《深度思考法》对逻辑定义为：逻辑就是关系
无逻辑就是没有建立起事物之间的正确关系，换句话说有逻辑就是能建立事物之间的正确关系
逻辑在系统中的体现
数据模型
建表时，表是实体，外键是关系
建多对多表时，中间表是关系
图数据库中的点是实体，边是关系
代码层面
用户对象有区域id属性，本质上是User对象与区域的关系
区域对象上有用户列表，也表示区域对象与多个用户的关系
map里的key,value就是1对1关系
业务层面上
用户分享链接，用户与链接的关系
用户参与某个活动，用户与活动的关系
用户参与活动达到了第二阶梯，本质上是用户与活动阶梯的关系
领域层面上
用户订单：用户域、订单域，原来用来领域之间的数据交互的上下文和防腐层可以直接用关系实例代替
举例说明
设计用户、区域、订单三个领域，如果我要查询某个区域下男性用户购买手机壳商品的订单列表。
可以通过用户与区域的关系找到这个区域下所有的用户，过滤出男性用户，再通过用户与订单关系查出所有用户的订单，过滤出买了手机壳的订单
那么你的代码如同你讲的话一样，只要逻辑通顺，代码连注释都不用了。
在这个设计中，关系的存在不一定落到数据库里才算关系，写到缓存，写到文件里都行，领域模型本身不关心实现，只要清晰能表达语义，所有的逻辑都很简单。简单的原因是因为大脑的思考是个关系连接的思考方式。
还有一个点，比如过滤手机壳订单可能因为订单过多，有性能问题，因为有可能订单本身就没有手机壳这个按类别建的索引，那么在建关系的时候，可以把手机壳这个类别做为属性存在关系中，并建立索引，那么所谓的性能问题都是范围特别小的问题。问题也更容易被拆解。
这种强化关系属性的思路源自图数据模型中给边建索引。
关系的表达是种正确的解决方案，那随之而来的，是不是关系会大量存在？
是的，但选择建不建关系和怎么建关系，取决于业务需不需要这层关系。关系的存在是多种形式的。设计思路上，如果以关系切入，很多问题就是if,else问题了。
例如
用户分享链接，用户是实体，链接是实体，用户与链接关系这层关系你需不需要，一般业务是不关心这种这个链接是谁发出来的，如果要关心，解法有多种，取决于业务对这块重视程度
1，链接上直接挂个用户id，这就能够表明这个链接是谁的了
2，建这redis的缓存，key是用户id，value是链接，链接失效期就是key的失效期
3，落库，将用户id,链接id和其他需要关心的字段存起来
如何减少关系
关系分类
可以将关系简单分类为1对1、1对多、多对多。可以从对象持有、缓存连接、数据库存储等方式表达关系
对象持有
- 1对1关系可以用对方对象持有已方id或对象形式
- 1对多关系对方对象持有已方list、map对象形式
- 多对多关系可以各自对象持有对方list、map对象形式
缓存连接
- 1对1关系可以用key-value形式表示
- 1对多关系可以用key-list、key-map形式
- 多对多关系可以用各自对象持有key-list、key-map形式
数据存储
- 1对1关系就是一条数据多个字段连接
- 1对多可以用多条数据连接
- 多对多也可以用多条数据，甚至中间表等实现
实现的方式有很多种，这些都不重要，重要的是思维方式
为了关系而强行映射？
是的，这是有必要的。这个就像机器深度学习原理一样，如果你发现了某种规律，为了证明这种规律，会拿大量的数据去训练，得出的结果不停的去纠正这种规律，以目前的实践样例来看，现阶段会认为这个结论是正确的。
所以，本文的观点是，谁主张，谁举证！
这是一种思路上的改变，如果你不认可，可以举出反例证明！
如果你认可这种思路，你会发现这个思路不仅在系统设计中有指导作用，在生活中，无处不是各种实体联系！具体有什么用，有点像佛家里讲的无用无不用。
高级语言中定义一切皆对象，而我们常常只把实体当对象，而关系本质上也是对象，是一个有属性、状态、生命周期的对象。它不像现实中的实物对象容易拟物化，从这点理解，关系也就合情合理了。
