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

但这里还有一个问题，就是微服务之间的通讯问题，你可以反复强调我们需要构建强大的分布式应用，但是推荐的技术栈是什么？如何去做？而且还要做的更好，这个并没有明确说明，所以大家选择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），也会帮助你很快学习，掌握这些方法论，回头你再使用图书和文章进行巩固一下，也是非常好的。
相关链接
[1]
[2]
[3]
[4]documentation/developers-guide
[5]
[6]
[7]
[8]
[9]
[10]docs/generic-freemarker-generator/
[11]
[12]
[13]
本文来源:微信公众号-阿里技术-雷卷
本文地址: