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

ContextMapper带来的收益
按照你的说法，我们用DSL代码方式来描述DDD ，这个有什么收益？
架构设计标准化
这种代码方式，一目了然且非常规范。如果你代码写错会有什么问题，当然是编译不通过， IDE都会帮你纠正。所以DDD DSL也是这样，完全无歧义。目前ContextMapper DSL包括Eclipse和VS Code插件，在IntelliJ IDEA可以通过自定义File Types和Live template方式来辅助你编写cml文件。
生成器(Generators)支持
前面我们聊到DDD DSL支持代码生成器，可以辅助你生成代码，相信这个大家都能明白，因为DDD DSL代码是标准的，基于这个Code Model生成其他形式的代码，这个当然可以。
另外ContextMapper还支持其他模型生成，如ContextMap图形化展现、PlantUML的结构图，对应的代码在这里[9] 。我这里给大家一些截图：

当然ContextMapper还提供通用的生成器，也就是基于DDD DSL模型，加上Freemarker模板，然后就可以生成你想要的各种输出，如生成JHipster Domain Language (JDL)用于快速创建文件脚手架也不奇怪。相信很多Java程序员对此都不陌生，我们开发Web应用时就是使用Freemarker生成HTML的。更多细节访问这里[10] 。
现实中的DDD设计流程
我们有了DDD DSL来描述我们的架构设计，是不是就全面了，完全够用，开发不愁了呢。还不是，我们知道在软件架构设计和编写代码前，都有需求调研、客户走访、领域专家沟通、需求分析、研讨等等，这个在现实生活中还是少不掉的，其目的就是为了后续的架构设计提供素材并做铺垫。那么如何将DDD和这些前期操作整合起来？其实DDD有涉及这方面的内容，如EventStorming卡片：
图源：
Bounded Context Canvas卡片：
图源：
如果你在需求分析阶段注意这些DDD卡片的使用，那么后续的DDD设计就会有更好的素材，当然还有UserStory和Use Case等。
个人建议：如果你有时间的话，强烈建议关注一下 ddd-crew[11]，有非常全面的DDD相关的最新并实用的知识和实践。
DDD和MicroServices的关系
和DDD DSL无关，只是稍微提及一下。微服务架构设计在于如何将复杂的业务系统划分为密切合作的微服务应用，划分的依据就显得非常重要。 SubDomain从业务的角度出发，进行业务边界的划分，而BoundedContext则是关注于业务领域对应的应用承载。而Generic类型BoundedContext可以同时支撑多个SubDomain ，能够做到不同业务系统的应用复用。如果在Cloud Native的场景中，我们希望更多的使用System类型的BoundedContext ，也就是重复利用云上的系统，从而减少自己的开发和维护成本。回到Appplication类型的BoundedContext ，这个就是你要具体开发的应用，你选择哪些微服务框架，这个你可以自行决定。整个过程， DDD都起到应用划分的理论基础作用。