智能手推车使零售店更智能

Context Map

ContextMap主要是描述各个Domain中各个BoundedContext间的关联关系，你可以理解为BoundedContext的拓扑地图。这里我们先不详细介绍BoundedContext，你现在只需要理解为实现Domain的载体，如你编写的HSF服务应用、一个处理客户请求的Web应用或者手机App，也可以是你租用的一个外部SaaS系统等。举一个例子，你的系统中有一个blog的SubDomain，你可以自行开发，也可以架设一个WordPress，或者用Medium实现Blog。回到微服务的场景，如何划分微服务应用?SubDomain对应的是业务或者虚拟的领域，而BoundedContext则是具体支持SubDomain的微服务应用，当然一个SubDomain可能对应多个微服务应用。

既然是描述各个BoundedContext关系，必然会涉及到关联关系，如DDD推荐的Partnership([P]<->[P])、Shared Kernel([SK]<->[SK])、Customer/Supplier([C]<-[S])、Conformist(D,CF]<-[U,OHS,PL])、Open Host Service、Anticorruption Layer([D,ACL]<-[U,OHS,PL])、Published Language等，详细的介绍大家可以参考DDD图书。这些对应关系都有对应的缩写，就是括号内的表述方法。这里给出关联关系Cheat Sheet说明图：
 

然目前我们还不知道对应的DSL代码语法，但是我们已经知道Domain的名称、domain类型以及domain的愿景陈述(visionStatement)，至于后期以何种方式展现系统Domain，如表格、图形等，这个可以考虑基于现在的数据进行展现。其中的UserTagDomain类型为GENERIC_SUBDOMAIN，这个表示打标是通用性Domain，如我们后期可以和商品、图片或者视频团队合作，大家可以一起共建打标系统。

注意：Subdomain不只是简单包括type和domainVisionStatement，同时你可以添加Entity和Service，其目的主要是突出核心特性并方便你对Domain的理解，如Account中添加resetPassword和authBySmsCode，相信大多数人都知道这是什么含义。但是注意不要将其他对象添加到Subdomain，如VO, Repository, Domain Event等，这些都是辅助开发的，应该用在BoundedContext中。
 

其中的概念，如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、成熟硬件系统等，你购买就可以啦。
• 支撑(Supporting) Domain：和通用Domain类似，但是系统更来自内部或者还需要在通用的基础上进行一些定制开发。如一个电商系统，会员、商品、订单、物流等业务系统，当然还有一些内部开发的技术类型支撑系统。
• 核心(Core) Domain: 也就是我们常说的业务核心，当然如果是技术产品，就是技术核心，这个也就是你最要关注的。

这三者整体关系如下：Core是最与众不同且花费精力比较多的，在复杂性Y维度，我们要避免高复杂度的通用和支撑Domain，这样会分散你的注意力，同时还要投入非常大的精力，如果确实需要，购买服务的方式可能最佳。

（编辑：平顶山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!