界限上下文 Bounded context

微服务之间依赖关系

微服务依赖关系的准则为：上游系统不需要知道下游系统的信息，否则请重新审视系统架构

换句话说，被调用者不需要知道调用方的信息，否则这不是一个合理的依赖。

比如在微服务设计时，如果domain service需要通过一个 from 参数，根据不同的渠道做出不同的行为，这对系统的拓展是致命的。例如，用户服务对于访问他的来源不应该知晓；用户服务应该对订单、商品、物流等访问者提供无差别的服务。

微服务之间集成方式

拆分微服务是为了更好的集成到一起，对于后续落地来说，还有服务集成这一重要的阶段。微服务之间的集成方式会受到很多因素的制约，前面在讨论微服务到底有多微的时候就顺便提到了集成会带来成本，处于不同的目的可以采用不同的集成方式。

  1. 采用 RPC（远程调用） 的方式集成。使用RPC的方式可以让开发者非常容易的切换到分布式系统开发中来，但是RPC的耦合性依然很高，同时需要对RPC平台依赖。业界优秀的RPC框架有dubbo、Grpc、thrift等
  2. 采用消息的方式集成。使用消息的方式则改变的开发的逻辑，服务之间使用发布-订阅的方式交互。另外一种思想是IT系统不是数据的流动，而是改变系统状态的事件传递，因此产生了 Event Sourcing 这种集成模式，让微服务具备天然的弹性。
  3. 采用RESTful方式集成。RESTful是一种最大化利用HTTP协议的API设计方式，服务之间通过HTTP API集成。这种方式让耦合变得极低，甚至稍作修改就可以暴露给外部系统使用。

这三种集成方式耦合程度由高到低，适用于不同的场景，需要根据实际情况选择，甚至在系统中可能同时存在。服务间集成的方式还有其他方式，一般来说，上面三种微服务集成的方式可以概括目前常见系统大部分需求。

可视化架构和沉淀输出

第一次读DDD相关的资料和书籍时，没有记住DDD的很多概念，但是子域划分像极了潮汕牛肉火锅的划分图，给我留下深刻的印象。DDD 强调技术人员和业务人员共同协作，DDD 对图的绘制表现的非常随意自然。

微服务 - 图1

但是在做系统设计时，应该使用更为准确和容易传递的架构图，例如使用 C4 模型中的系统全景图(System Landscape diagram)来表达微服务之间的关系。当然你也可以使用UML来完成架构设计。C4 只是层次化（架构缩放）方式表达架构设计，和UML并不冲突。

系统架构图除了微服务的关系之外，也需要讲技术选型表达出来。

微服务集成方式除了通过架构图标识之外，最好也通过API列表的方式将事件风暴中的事件转换为API；除此之外，可以将DDD领域模型细化成聚合根、实体、值对象，请参考DDD的战术设计。