微服务，分层设计与领域驱动设计（DDD)？

当系统越来越复杂的时候，怎么将一个庞大的系统拆分成一个微服务，让后端服务能更好的迭代是一个架构师必须要具备的能力。

微服怎么拆，经典的就是分层设计了。分层架构如此经典，以至于成为我们每个程序员的标配了。随着服务的更加复杂，基于领域的设计就显得更加有必要了，这个时候分层设计和领域设计该怎么权衡？

其实准确的说，分层设计和领域设计不在一个维度，没有必然的联系。但是在领域驱动设计中也有分层的思想。

画外音：小孩子才做选择，成年人都要！

分层设计

对于大部分互联网公司来说，后端架构分为三层：网关层、业务逻辑层、数据访问层。

（1）网关层：负责提供对外的HTTP服务或者其他应用服务。

（2）业务逻辑层：负责处理核心业务逻辑，

（3）数据访问层：负责对数据库的增删改查，对业务逻辑屏蔽底层存储介质。

随着业务的复杂度增加，必然带来技术的复杂度增加。但是引起技术实现变化的原因与引起业务逻辑发生变化的原因显然不同，这就导致架构上对于基础设施（技术）和领域逻辑（业务）会以不同的速率发生变化。技术复杂性和领域复杂性的分离就是一种解决办法了。

画外音：架构的单一职责原则，拆！

领域驱动设计的经典分层

目前似乎没有一家公司真正严格按照DDD进行项目代码设计。根据DDD理论，领域建模主要发生在领域服务层，各领域模块都应该是高内聚低耦合的，具有清晰的业务边界。领域驱动设计在经典三层架构的基础上做了进一步改良。

（1）应用层：很薄的一层，用来协调应用的活动，它不包含业务逻辑，它不保留业务对象的状态，但它保有应用任务的进度状态。

（2）领域层：包含关于领域的信息，这是业务软件的核心所在。

（3）基础设施层：作为其他层的支撑。它提供了层间的通信，实现对业务对象的持久化。

举个例子：

通过不同的业务领域，将交易拆分成订单、支付、物流等专业领域。通过统一的应用层实现不同的功能组合给不同的业务场景进行赋能了。

总结：

（1）领域设计一定要有清晰的功能边界

（2）领域拆分并不是一步到位的，应当根据实际情况逐步展开

（3）领域拆分并不是一成不变的，应当具体情况具体分析

任何脱离业务的架构设计都是耍流氓