微服务内高内聚，微服务间低耦合。

“核心通讯录”微服务只负责发送变更消息到消息队列，不管谁会接收并处理这些消息；

“门禁管理”微服务只负责接收照片变更消息，不管谁发送的这个消息。

1. 按照限界上下文进行微服务的拆分，将领域模型划分到多个问题子域

2. 基于充血模型与贫血模型设计各个微服务的业务领域层（Service、Entity、Value）

3. 通过领域事件通知机制和微服务调用的推拉结合，将各个子域进行解耦关联

   • 核心：

• 通讯录 | 短信 | 推送通知 | 支付 | 文件服务

• 智慧通行

  解决物业多品牌、多系统应用造成的信息孤岛，数据混乱的问题

  • 人脸门禁 | 可视对讲 | 电梯梯控 | 停车系统 | 访客预约

• 安全社区

  通过图像视频识别、传感数据采集，实现报警联动和风险预警

  • 视频监控 | 周界报警 | 高空抛物 | 跨域追踪

• 全屋智能

  围绕业主需求，逐步引入社区医疗、社区养老、社区团购、社区家政等服务

  • 超级面板 | 无线门锁 | 烟感雾感

• 增值服务

  实现跨品牌的产品体验，支持基于matrix引擎的智能生活场景裂变能力

  - 智能充电 | 云广播 | 出入提醒 | 定向投放

   

通过合理的微服务设计，尽量让每次的需求变更都交给某个小团队独立完成，让需求变更落到某个微服务上进行变更。唯有这样，每次变更只需独立地修改这个微服务，独立打包、独立升级，新需求独立实现，才能发挥微服务的优势。

• 数据隔离：数据库中用户信息表的读写只有通讯录微服务。当其他微服务需要读写用户信息时，就不能直接读取用户信息表，而是通过 API 接口去调用通讯录微服务。
• 接口复用：因此，当多个团队向你提需求时，必须要对这些接口进行规划，通过复用尽可能少的接口满足他们的需求；当有新的接口提出时，要尽量通过现有接口解决问题。
• 向前兼容：当调用方需要接口变更时怎么办？变更现有接口应当尽可能向前兼容，即接口的名称与参数都不变，只是在内部增加新的功能。宁愿增加一个新的接口也最好不要去变更原有的接口。

• 本地调用：在访客申请微服务的本地，增加一个查询用户Service的 feign 接口。这样，访客申请Service就像本地调用一样调用查询用户Service，再通过 feign 接口实现远程调用。这种防腐层的设计，可以隔离当前微服务以外的其他微服务拆分变更导致的接口的失效的影响。

• 数据库去中心化：

  • 微服务中通讯录服务与健康码服务分别对应的用户库与权限库，它们的共同特点是数据量小但频繁读取，可以选用小型的 MySQL 数据库并在前面架设 Redis 来提高查询性能；

  • 微服务中访客通行与生活缴费分别对应的通行记录库、订单库，其特点是数据量大并且高并发写，选用一个数据库显然扛不住这样的压力，因此可以选用了 TiDB 这样的 NewSQL 数据库进行分布式存储，将数据压力分散到多个数据节点中，从而解决 I/O 瓶颈；

  • 微服务中数据分析与通讯录查询这样的查询分析业务，则选用 NoSQL 数据库或大数据平台，通过读写分离将生产库上的数据同步过来进行分布式存储，然后宽表一系列的预处理，应对海量历史数据的决策分析与秒级查询。（ NoSQL 为空的字段是不占用空间的，因此字段再多都不影响查询性能）

贫血模型、充血模型、策略模式、装饰者模式只是DDD实现的方式，而DDD的真谛是领域建模。

做事不能仅凭一腔热血，一定要符合自然规律。其实软件的设计开发过程也是这样。对业务理解不深刻全局架构设计往往是过度设计，这时候应该抓主要流程，开始领域建模。

• 接着，每次添加新功能的时候，一方面要满足当前的需求，另一方面业务相关的领域建模设计刚刚满足需求，从而使设计最简化、代码最少。

• 这样的设计过程叫小步快跑。采用小步快跑的设计方法，一开始不用思考那么多问题，从简单问题开始逐步深入。领域模型就像小树一样一点儿一点儿成长，最后完成所有的功能。

保持软件设计不退化的关键在于每次需求变更的设计，只有保证每次需求变更时做出正确的设计，才能保证软件以一种良性循环的方式不断维护下去。

有没有一种方法，让我们在第十次变更、第二十次变更、第三十次变更时，依然能够找到正确的设计呢？有，那就是领域驱动设计。

那么在每次需求变更时，将变更还原到真实世界中，看看真实世界是什么样子的，根据真实世界进行变更。