DDD as Code:如何用代码诠释领域驱动设计?(3)

简介: DDD as Code:如何用代码诠释领域驱动设计?

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



image.png


图源:https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet

Bounded Context Canvas卡片:



image.png


图源:https://github.com/ddd-crew/ddd-starter-modelling-process如果你在需求分析阶段注意这些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),也会帮助你很快学习,掌握这些方法论,回头你再使用图书和文章进行巩固一下,也是非常好的。

相关链接 [1]http://sculptorgenerator.org/ [2]https://github.com/fuinorg/org.fuin.dsl.ddd [3] https://contextmapper.org/ [4]http://sculptorgenerator.org/documentation/developers-guide [5]https://leanpub.com/visualising-software-architecture

[6]https://github.com/fuinorg/ddd-4-java

[7]https://github.com/odrotbohm/jddd

[8]https://github.com/linux-china/ddd-base

[9]https://github.com/ContextMapper/context-mapper-examples

[10]https://contextmapper.org/docs/generic-freemarker-generator/
[11]https://github.com/ddd-crew [12]https://speakerdeck.com/mploed/microservices-love-domain-driven-design-why-and-how [13]https://contextmapper.org/
相关文章
|
2月前
|
消息中间件 测试技术 领域建模
DDD - 一文读懂DDD领域驱动设计
DDD - 一文读懂DDD领域驱动设计
480 0
|
9月前
|
消息中间件 架构师 搜索推荐
DDD领域驱动设计的概念解析
DDD领域驱动设计的概念解析
161 0
|
11月前
|
前端开发 架构师 Java
领域驱动设计DDD从入门到代码实践
在本文中,作者将借鉴《实现领域驱动设计》的做法,介绍领域驱动设计的基本概念的同时,用一个虚拟的公司和一个虚拟的项目,把领域驱动设计进行落地实践。
11198 9
领域驱动设计DDD从入门到代码实践
|
IDE Java 程序员
DDD as Code:如何用代码诠释领域驱动设计?(2)
DDD as Code:如何用代码诠释领域驱动设计?
194 0
|
Kubernetes 前端开发 架构师
DDD as Code:如何用代码诠释领域驱动设计?(1)
DDD as Code:如何用代码诠释领域驱动设计?
141 0
|
前端开发 JavaScript NoSQL
DDD实战之二:看看代码结构长啥样
DDD实战之二:看看代码结构长啥样
DDD实战之二:看看代码结构长啥样
|
项目管理
DDD案例(1):从需求分析到领域分析(4)
DDD案例(1):从需求分析到领域分析(4)
424 0
DDD案例(1):从需求分析到领域分析(4)
|
设计模式 缓存 Java
DDD之代码架构
这是一篇迟到的文章。这其实是我写DDD的第四篇文章。去年11月份左右我在个人网站上写了三篇关于DDD的文章,都是比较偏战略部分的。那个时候我还在一个正在使用DDD的项目上,也是我第一次真正开始深入使用DDD。
552 1
|
供应链 安全 领域建模
DDD案例(1):从需求分析到领域分析(6)
DDD案例(1):从需求分析到领域分析(6)
322 0
DDD案例(1):从需求分析到领域分析(6)
DDD案例(1):从需求分析到领域分析(5)
DDD案例(1):从需求分析到领域分析(5)
230 0
DDD案例(1):从需求分析到领域分析(5)