学会这几招可以假装是Python高手

如果你在需求分析阶段注意这些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都起到应用划分的理论基础作用。

但这里还有一个问题，就是微服务之间的通讯问题，你可以反复强调我们需要构建强大的分布式应用，但是推荐的技术栈是什么?如何去做?而且还要做的更好，这个并没有明确说明，所以大家选择REST API、gRPC、RPC，Pub/Sub等等混合通讯技术栈。

关于BoundedContext之间的关联关系DDD已经给出了(partner ship, c/s, share kernel等)，但是具体到通讯和协作，并没有给出很好的理论基础， 但是这个在DDD社区也有一些共识，就是基于异步化的消息通讯 + 事件驱动是比较好的方案，所以你看到DDD的首席布道师Vaughn Vernon反复讲到DDD + Reactive，就是为了解决ContextMapping的通讯问题。

说到这里，如果你看到ContextMapper支持MDSL (Micro-)Service Contracts Generator的输出，那么也就不奇怪了，也是理所当然的事情。

更多的关于MicroServices和DDD关系，你可以参考《Microservices love Domain Driven Design, why and how?》[12]

总结

ContextMapper提出的DSL概念还是非常好的，至少让大家在DDD的理解上歧义少啦，同时也规范啦，DDD初学者的门槛也降低，虽不能到架构设计的地步，至少阅读理解起来无障碍。在我编写这篇文章的时候，ContextMapper DSL 5.15.0版本已经发布，相关的特性都已经全部开发完毕啦，使用起来还是非常顺畅的。当然落实到实际开发，DDD as Code这种方式是否有效，还希望做DDD实践的同学给出宝贵的意见。

当然我一篇文章并不能将ContextMapper阐述的非常清楚，contextmapper[13]上有非常详细的文档和对应的相关论文， 当然你可以不采用DSL这一套思路，但是这些思想和相关的资料对DDD设计还是帮助非常大的。

另外个人更觉得，如果你是DDD的初学者，那么ContextMapper可能更合适，DDD是方法论，那些图书都枯燥的要死，看两章节不犯困几乎非常难的。相反如果你学习DDD DSL那就简单多，这个DSL再复杂也不会比你学习的编程语言复杂吧?相反这个DSL是非常简单的，通过简单的DDD DSL学习，你会很快掌握其中的概念、思路和方法，不行就看一下其他人的代码(DDD DSL examples)，也会帮助你很快学习，掌握这些方法论，回头你再使用图书和文章进行巩固一下，也是非常好的。

 

然ContextMapper还提供通用的生成器，也就是基于DDD DSL模型，加上Freemarker模板，然后就可以生成你想要的各种输出，如生成JHipster Domain Language (JDL)用于快速创建文件脚手架也不奇怪。相信很多Java程序员对此都不陌生，我们开发Web应用时就是使用Freemarker生成HTML的。更多细节访问这里[10]。

现实中的DDD设计流程

我们有了DDD DSL来描述我们的架构设计，是不是就全面了，完全够用，开发不愁了呢。还不是，我们知道在软件架构设计和编写代码前，都有需求调研、客户走访、领域专家沟通、需求分析、研讨等等，这个在现实生活中还是少不掉的，其目的就是为了后续的架构设计提供素材并做铺垫。那么如何将DDD和这些前期操作整合起来?其实DDD有涉及这方面的内容，如EventStorming卡片：
 

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]。我这里给大家一些截图：

（编辑：平顶山站长网）

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