如何从0到1实践DDD(2)
画完草图之后，感觉不是很确定，于是便去咨询部门的DDD专家王老师（十分感谢王立老师的指导），得到了一些宝贵的建议：我们应该避免直接从表现层去看业务，表现层就像是冰山露在水面上的棱角，这些棱角看起来毫不相干，但是实际上底层是连成一块的，这些才是我们需要关注的。
就像这个项目，表面上商户和设备是分开的，实际上它们在操作都是我们的增值运营产品，应该看成我们的系统提供统一对外的服务，然后商户和设备来使用我们的服务。UGC内容存储业务用例其实没有涉及到的，属于实现时候的东西。一番建议让我们理清了思路，于是重新梳理，得到以下的战略建模图：
整体而言，我们将整体系统梳理为8个子域：
增值运营服务子域：核心域，是我们业务主要竞争力。从业务上来讲，我们的核心是通过提供业务中IoT设备上的增值运营服务
增值运营产品子域：支撑域，这里主要是我们提供增值运营产品，如电子海报、互动海报等
生效场景子域：支撑域，业务中增值运营产品有不同生效场景，这里统一进行管理
准入子域：支撑域，现主要是业务中对使用者的一些限制规则
权限管理子域：支撑域，基于角色来管理使用者的权限
商户信息子域：支撑域，提供商户的信息
IoT设备信息子域：支撑域，提供IoT设备的信息
风险识别子域：通用域，识别业务中一些安全风险，如不合规的UGC素材等。这部分是业界常见问题，可以使用通用方案来解决，实际上我们也是接入TEG的能力来实现
其中我们系统中的商户信息依赖了微信支付商户账号信息和IoT设备铺设服务信息，这里使用防腐层进行隔离，将外部的商户信息“翻译”为我们业务中的商户信息。三、如何实现DDD之战术建模梳理清楚上下文之间的关系后，我们基本了解业务的概貌，接下来需要细化上下文，进一步完善我们的模型。这里也需要用到DDD的一些基本概念。
3. 基本概念
1）实体、值对象
实体和值对象是组成领域模型的基础单元。当一个对象由其标识（而不是属性）区分时，这种对象称为实体。如在校园教务系统中，每个账户是对应着一个学生，根据学号来唯一标识，可以认为是一个实体。传统的数据建模大多是根据数据库范式设计的，每一个数据库表对应一个实体，每一个实体的属性值用单独的一列来存储，一个实体主表会对应 N 个实体从表。
与其不同，DDD 是先构建领域模型，再将业务对象映射为持久化对象。这可能导致DDD建立出来的实体，映射到具体数据库表时，可能是1对多，多对1的关系。
如一个账户实体，有它的基本信息和权限角色信息，可能就对应了2个持久化对象。另一方面，有时候为了某些查询场景的方便，会把教师账户、学生账户等对应成一个持久化对象，就成了多对1。
通过对象属性值来识别的对象，则可以认为是一个值对象。如地址信息{“省”: “广东省”，”市”:”深圳市”}，我们是通过它的属性来区分出不同的地址。值对象实际上是想把一些不变的属性组合起来，减少系统的复杂性。在设计值对象的时候，需要满足以下的特性：
值对象相等性：可以通过对其属性的比较，来区分不同的值对象
不变性：需要保证值对象创建后就不能被修改，即不允许外部再修改其属性
可替换性：值对象是一个整体，当其描述的对象有变化时，需要用一个新的值对象来替换对于值对象，由于其具有不变性，且是通过属性来判断相等的，在设计对应的数据库持久化对象时，可以将其以JSON形式存储在数据库表的某一字段中
2）聚合、聚合根
在 DDD 中，实体和值对象是基础的领域对象。实体一般对应业务对象，它具有业务属性和业务行为；而值对象主要是属性集合，对实体的状态和特征进行描述。但是我们的一个业务流程中，一般会同时涉及多个实体、值对象的操作，这里业务逻辑紧密的实体和值对象便组合成一个聚合。
从数据层面来看，同个聚合内的数据需要保持强一致性。
每一个聚合有一个聚合根实体，设置聚合根的主要目的是为了避免由于复杂数据模型缺少统一的业务规则控制，而导致聚合、实体之间数据不一致性的问题。聚合根可以看成是聚合的管理者，或是说handle。对内其协调实体和值对象完成业务逻辑。对外则提供通过聚合ID供其他聚合关联引用，屏蔽外部对内部实体的直接访问和修改。
建议的聚合设计原则：
在一致性边界之内确保不变性：聚合用来封装真正的不变性，而不是简单地将对象组合在一起。聚合内有一套不变的业务规则，各实体和值对象按照统一的业务规则运行，实现对象数据的一致性。
设计小聚合：如果聚合聚合包含过多的实体，会提高管理实体的复杂性，高频操作下容易并发冲突，降低了系统的性能。
在边界之外使用最终一致性：不同的聚合之间不要求强一致性，保证最终一致性。一次事务操作中，只修改一个聚合实例，如果需要修改多个实例，可以考虑通过异步的方式保证最终一致性。
3）领域服务
领域服务的定义：领域中的服务表示一个无状态的操作，它用于实现特定于某个领域的任务。当某个操作不适合放在聚合（实体）或值对像上时，最好的方式便是使用领域服务。
举个例子，在一个路线导航的项目中，“路线”可能是其中的一个实体，如果业务中有“推荐路线上相关的美食”这样一个功能，那我们会想，这个功能应该归给哪个领域对象，给“路线”实体吗？有点不合适，应该路线本身关注的是起终点，时间人物等。
此时可以将其这个功能归为领域服务，它是一个路线状态无关的服务，输入路线各个节点，来得到沿路的各种美食。当然，要注意不要过度地使用领域服务，因为这很可能导致你把实体的行为都放在里面了，实体本身都变成了一些只有getter和setter的“贫血模型”。
4）领域事件
领域事件是领域模型中非常重要的一部分，用来表示领域中发生的事件。一个领域事件将导致进一步的业务操作，在实现业务解耦的同时，还有助于形成完整的业务闭环。
>相关《 如何从0到1实践DDD(2)》内容：
1、 「盘中宝周回顾」震荡行情如何解局？看VIP“大浪淘沙”精选优质资讯
理财鱼小提示：「盘中宝周回顾」震荡行情如何解局？看VIP“大浪淘沙”精选优质资讯 「盘中宝周回顾」震荡行情如何解局？看VIP“大浪淘沙”精选优质资讯 截至12月24日（本周五），上证指数今年上涨4.17%，深证成指今年上涨239点，年涨幅为1.66%，创业板指数今年涨...【继续阅读】
2、 碧桂园实践精益管理：建筑机器人助力“碳中和”聚焦产品力赋能高质量发展
理财鱼小提示：碧桂园实践精益管理：建筑机器人助力“碳中和”聚焦产品力赋能高质量发展 记者 黄婉银 当前房地产市场面临周期调整，各个房企都在寻找降本增效的秘密，逐步强调：向管理要效益、强品质提溢价、精运营降成本、细生产省时间等等。 各个房企纷纷向制...【继续阅读】
3、 【盘中宝周回顾】震荡行情如何解局？看VIP“大浪淘沙”精选优质资讯
截至12月24日（本周五），上证指数今年上涨4.17%，深证成指今年上涨239点，年涨幅为1.66%，创业板指数今年涨幅最大，目前年涨幅为11.15%。由于距2021年股市收官只剩下最后一周，即使盘面下周震荡，三大股指年线收阳依旧为大概率事件。 从行业来看，申万一...【继续阅读】