原文标题：这些年背过的面试题——领域模型落地篇
原文作者：阿里云开发者
冷月清谈：
- 内高内聚：单一职责原则，每个微服务专注于自己的业务领域。
- 间低耦合：开放封闭原则，微服务通过接口调用，实现业务领域分离。
关联微服务
- 限界上下文：基于业务场景划分子域，每个子域都有独立的领域对象。
- 领域事件通知：通过消息队列实现微服务间的领域事件通知，解耦各个子域。
- 聚合和关联：通过贫血模型或充血模型设计业务领域层，实现微服务之间的聚合和关联。
微服务的落地
- 需求变更独立性：微服务设计要确保需求变更可以由某个小团队独立完成，发挥微服务优势。
- 数据隔离和接口复用：通过接口复用和数据隔离，降低微服务拆分变更的影响。
- 本地调用和防腐层：使用本地调用和防腐层设计，隔离不同微服务接口变更的影响。
- 数据库去中心化：根据数据量、读写模式等因素选择合适的数据库方案，实现数据库去中心化。
领域模型的意义
- 理解真实世界：领域建模还原真实世界的业务场景，指导软件设计。
- 小步快跑：每次需求变更都应基于领域建模完善设计，保持软件设计的良性循环。
怜星夜思：
2、领域模型落地的关键是什么？
3、在微服务中，数据隔离和接口复用的目的是什么？
原文内容
阿里妹导读
一、拆分微服务
微服务内高内聚，微服务间低耦合。
“核心通讯录”微服务只负责发送变更消息到消息队列，不管谁会接收并处理这些消息；“门禁管理”微服务只负责接收照片变更消息，不管谁发送的这个消息。
二、关联微服务
-
按照限界上下文进行微服务的拆分，将领域模型划分到多个问题子域
-
基于充血模型与贫血模型设计各个微服务的业务领域层（Service、Entity、Value）
-
通过领域事件通知机制和微服务调用的推拉结合，将各个子域进行解耦关联
-
核心：
-
通讯录 | 短信 | 推送通知 | 支付 | 文件服务
-
智慧通行
解决物业多品牌、多系统应用造成的信息孤岛，数据混乱的问题
-
人脸门禁 | 可视对讲 | 电梯梯控 | 停车系统 | 访客预约
-
安全社区
通过图像视频识别、传感数据采集，实现报警联动和风险预警
-
视频监控 | 周界报警 | 高空抛物 | 跨域追踪
-
全屋智能
围绕业主需求，逐步引入社区医疗、社区养老、社区团购、社区家政等服务
-
超级面板 | 无线门锁 | 烟感雾感
-
增值服务
实现跨品牌的产品体验，支持基于matrix引擎的智能生活场景裂变能力
- 智能充电 | 云广播 | 出入提醒 | 定向投放
三、微服务的落地
通过合理的微服务设计，尽量让每次的需求变更都交给某个小团队独立完成，让需求变更落到某个微服务上进行变更。唯有这样，每次变更只需独立地修改这个微服务，独立打包、独立升级，新需求独立实现，才能发挥微服务的优势。
-
数据隔离：数据库中用户信息表的读写只有通讯录微服务。当其他微服务需要读写用户信息时，就不能直接读取用户信息表，而是通过 API 接口去调用通讯录微服务。
-
接口复用：因此，当多个团队向你提需求时，必须要对这些接口进行规划，通过复用尽可能少的接口满足他们的需求；当有新的接口提出时，要尽量通过现有接口解决问题。
-
向前兼容：当调用方需要接口变更时怎么办？变更现有接口应当尽可能向前兼容，即接口的名称与参数都不变，只是在内部增加新的功能。宁愿增加一个新的接口也最好不要去变更原有的接口。
-
本地调用：在访客申请微服务的本地，增加一个查询用户Service的 feign 接口。这样，访客申请Service就像本地调用一样调用查询用户Service，再通过 feign 接口实现远程调用。这种防腐层的设计，可以隔离当前微服务以外的其他微服务拆分变更导致的接口的失效的影响。
-
数据库去中心化：
-
微服务中通讯录服务与健康码服务分别对应的用户库与权限库，它们的共同特点是数据量小但频繁读取，可以选用小型的 MySQL 数据库并在前面架设 Redis 来提高查询性能；
-
微服务中访客通行与生活缴费分别对应的通行记录库、订单库，其特点是数据量大并且高并发写，选用一个数据库显然扛不住这样的压力，因此可以选用了 TiDB 这样的 NewSQL 数据库进行分布式存储，将数据压力分散到多个数据节点中，从而解决 I/O 瓶颈；
-
微服务中数据分析与通讯录查询这样的查询分析业务，则选用 NoSQL 数据库或大数据平台，通过读写分离将生产库上的数据同步过来进行分布式存储，然后宽表一系列的预处理，应对海量历史数据的决策分析与秒级查询。（ NoSQL 为空的字段是不占用空间的，因此字段再多都不影响查询性能）
四、领域模型的意义
贫血模型、充血模型、策略模式、装饰者模式只是DDD实现的方式，而DDD的真谛是领域建模。
做事不能仅凭一腔热血，一定要符合自然规律。其实软件的设计开发过程也是这样。对业务理解不深刻全局架构设计往往是过度设计，这时候应该抓主要流程，开始领域建模。
-
接着，每次添加新功能的时候，一方面要满足当前的需求，另一方面业务相关的领域建模设计刚刚满足需求，从而使设计最简化、代码最少。
-
这样的设计过程叫小步快跑。采用小步快跑的设计方法，一开始不用思考那么多问题，从简单问题开始逐步深入。领域模型就像小树一样一点儿一点儿成长，最后完成所有的功能。
保持软件设计不退化的关键在于每次需求变更的设计，只有保证每次需求变更时做出正确的设计，才能保证软件以一种良性循环的方式不断维护下去。
有没有一种方法，让我们在第十次变更、第二十次变更、第三十次变更时，依然能够找到正确的设计呢？有，那就是领域驱动设计。
那么在每次需求变更时，将变更还原到真实世界中，看看真实世界是什么样子的，根据真实世界进行变更。
五、战略建模
六、相关名词
-
表单工厂分别调用表单信息DAO、表单明细 DAO 和用户DAO 去进行查询；
-
将得到的表单明细对象、用户对象进行装配，分别 set 到表单信息对象的表单明细与用户属性中；
-
最后，表单工厂将装配好的表单对象返回给表单仓库。
-
当客户程序通过 ID 去获取某个领域对象时，仓库会通过这个 ID 先到缓存中进行查找：
-
查找到了，则直接返回，不需要查询数据库；
-
没有找到，则通知工厂，工厂调用 DAO 去数据库中查询，然后装配成领域对象返回给仓库。
-
仓库在收到这个领域对象以后，在返回给客户程序的同时，将该对象放到缓存中。
【这些年背过的面试题】系列文章欢迎点击阅读原文查看合集！