DDD专栏7：DDD如何指导微服务设计实现

​ 上一讲中，针对支付风控系统，使用DDD的事件风暴，我们设计出了一个简单的领域模型。这一讲将会介绍如何使用DDD的领域模型来指导微服务架构设计。

微服务拆分原则

​ 微服务的技术架构其实并不是很难，SpringCloud技术体系已经很好的涵盖了微服务实现以及运维的方方面面。但是，很多软件开发团队在进行微服务转型时，会把关注点过多的集中在对微服务技术架构的学习上。然而，当他们真正开始将微服务落地到具体的业务时，会发现，微服务架构落地真正的难点是在微服务拆分上。针对一个固定的需求，开发团队大都能够根据自己的经验设计出比较好的微服务架构，但是当面对业务的频繁变更时，架构设计的差距就会体现出来了。这时就需要有一种方法论来指导如何微服务如何进行拆分，按照什么原则进行拆分，以及会面对哪些潜在的风险。

​ 微服务拆分的原则应该是服务内高内聚，服务间低耦合。

​ "高内聚"就需要微服务严格遵循"单一职责"原则。这就要求每个微服务内封装一个完整的造成业务变更的原因。面对需求变更时，所需要修改的代码都集中到这个微服务内，而与其他微服务无关。最理想的状态是以后进行需求变更时，只要把这一个微服务修改好，独立开发，独立部署，就可以实现需求。这样就能最大限度的体现微服务的优势。当然，这种理想，在面对复杂业务时，往往是不太现实的。所以从领域驱动设计的角度来看，就要求每个微服务内封装一个完整的业务子域。后续的需求变更可以分解成各个领域内的业务动作，而每个业务动作可以由一个微服务来独立完成，这样就能提高微服务的内聚性。

​ "低耦合"就要求每个微服务拥有集群架构内的唯一性。每个微服务都有自己的业务范围，而不属于自己