DDD领域驱动设计(二)

软件系统复杂性的应对

解决复杂和大规模软件的武器可以粗略的归位三种:抽象 分治和知识

• 抽象: 使用抽象能够精简问题空间，而且问题越小越容易理解。比如你去一个地方 一开始的时候并不需要确定用什么方式到达。
• 分治: 类似算法里面的dp用的就是分治的想法。分割后的问题需要足够小，方便一个人解决它。然后考虑如何组合这些分割的小东西。分割的越合理越容易理解，在搭积木的时候更加容易。用业界的话来说就是 <高内聚低耦合>
• 知识 顾名思义 DDD就是知识中的一种

与微服务架构相得益彰

微服务架构众所周知。不做赘述。我们创建一个微服务时，需要创建一个高内聚 低耦合的微服务。而DDD的限界上下文则完美匹配微服务的特点。这样就能轻松划分出一个微服务。就是DDD的上下界。

在系统复杂之后。我们都需要使用分治来拆解问题。一般有两种方式，技术维度和业务维度。技术维度类似MVC分层设计。一种就是按照业务领域来划分。
微服务架构强调用业务维度来分治应对系统复杂度。而DDD也同样着重业务视角。
在追求目标达到了统一。

我们将架构设计活动精简为以下三个层面:

• 业务架构----根据业务需求设计业务模块及其关系
• 架构系统----设计系统和子系统的模块
• 技术架构----决定采用的技术和框架

以上三种活动在实际开发中是有先后顺序的。但是不一定谁先谁后。在我们解决常规套路问题时，我们很自然往分层架构套(先确定系统架构)，或者用PHP开发(确定技术架构) 在业务不复杂的情况下 没啥毛病。
跳过业务架构设计出来的架构关注点不在业务响应上。可能就是个大泥球。在面临需求迭代或者响应市场变化时就会很痛苦。

DDD的核心诉求就是将业务架构映射到系统架构上，在响应业务变化调整业务架构的时候，也能随时调整系统架构。而微服务追求业务层面的复用。设计出来的系统架构和业务一致。在技术架构上则系统模块之间充分解耦。可以自由地选择合适的技术架构，去中心化地治理技术和数据

DDD与微服务关系映射

用原来的抽奖来做个简单的例子。用DDD重构完成一个中型的基于微服务架构的系统。来做到高内聚低耦合