苏眠月|DDD as Code：如何用代码诠释领域驱动设计？( 二 ) 1234567891011121314151

战术设计(Tactic DDD)：Entity, Value Object; Aggregate, Root Entity, Service, Domain Event; Factory, Repository 。

战略设计(Strategic DDD)：Bounded Context, Context Map; Published Language, Shared Kernel, Open Host Service, Customer-Supplier, Conformist, Anti Corruption Layer (context relationship types) 。

其实也比较简单，战略设计更大一些，偏宏观，你可以理解为公司高层在讨论的业务和技术方向，各个团队或者产品的分工和配合；而战术设计则相对小很多，主要集中在一个BoundedContext内部，比如如何设计DDD那些Entity ， Service ， Repository等，外加可能的应用开发的技术选型，可以说更关注技术层面。
ContextMapper框架介绍
ContextMapper是一个开源项目[3]，主要是为DDD设计提供DSL支持，如DDD的战略(Strategic)设计， Context间映射(Context Mapping) ， BoundedContext建模以及服务解耦(Service Decomposition) ，那么我们就看一下如何基于ContextMapper来完成一个项目基于DDD DSL的表达。
在介绍ContextMapper时，我们先交代一下项目背景。如花是一名架构师，对DDD也非常熟悉，而且有过几个项目的DDD实践，最近他加入会员线，负责完成对会员系统的改造，更好地配合公司的微服务化的设计思路。会员线之前就是三个应用：会员中心对外提供的大量的REST API服务；会员注册和登录应用；会员中心，处理会员登录后如修改个人密码、基本信息、SNS第三方绑定和支付方式绑定等。
如花加入会员团队后，和大家沟通了基于DDD + MicroServices的架构思想，大家都表示同意，但是如何落实到具体的架构设计和文档上，大家就犯难啦。让我们看一下最典型的DDD设计图：

其中的概念，如SubDomain、BoundedContext、Entity、ValueObject、Service、 Repository、Domain Event ，以及Context映射关系(Context Mapping) ，这些都没有问题，但是如何向他人表达这个思想？总不能每次都把DDD设计图和分层图都贴上去，然后说我就是按照DDD设计的。
从SubDomain开始
如花开始DDD的第一步，也就是Subdomain的划分。当然DDD中包括三种类型的SubDomain ，分别为通用(Generic)、支撑(Supporting)和核心(Core)三种类型，这里稍微说明一下这几者的区别：

通用(Generic) Domain: 通用Domain通常被认为已经被行业解决的问题，如架构设计中的可观测性的Logging、Metrics和Tracing ，各种云服务(Cloud Service)等，这些都已经有比较好的实现方案，对接就可以。当然业务上也有，如成熟的行业解决方案，如ERP、CRM、成熟硬件系统等，你购买就可以啦。