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/
相关文章
|
9月前
|
IDE Linux API
轻松在本地部署 DeepSeek 蒸馏模型并无缝集成到你的 IDE
本文将详细介绍如何在本地部署 DeepSeek 蒸馏模型,内容主要包括 Ollama 的介绍与安装、如何通过 Ollama 部署 DeepSeek、在 ChatBox 中使用 DeepSeek 以及在 VS Code 中集成 DeepSeek 等。
2258 15
轻松在本地部署 DeepSeek 蒸馏模型并无缝集成到你的 IDE
|
机器学习/深度学习 PyTorch 算法框架/工具
【从零开始学习深度学习】31. 卷积神经网络之残差网络(ResNet)介绍及其Pytorch实现
【从零开始学习深度学习】31. 卷积神经网络之残差网络(ResNet)介绍及其Pytorch实现
|
机器学习/深度学习
Epoch、Batch 和 Iteration 的区别详解
【8月更文挑战第23天】
2447 0
|
10月前
|
机器学习/深度学习 算法 前端开发
图解前向、反向传播算法,一看就懂!
前向传播是神经网络中信息从输入层经过隐藏层传递到输出层的过程。每个神经元接收前一层的输出,通过加权求和和激活函数处理后传递给下一层,最终生成预测结果。此过程涉及输入信号、加权求和、激活函数应用等步骤。前向传播用于生成预测结果,在训练阶段与真实标签比较以计算损失函数,并在推理阶段直接生成预测值。反向传播则利用链式法则计算损失函数相对于权重的梯度,调整参数以减小误差,从而优化模型性能。两者结合实现神经网络的有效训练和预测。
|
11月前
|
弹性计算 分布式计算 监控
祝贺叠纸新游《无限暖暖》全球开服!阿里云全球基础设施持续护航
祝贺叠纸新游《无限暖暖》全球开服!阿里云全球基础设施持续护航
397 5
Elasticsearch 批量更新
讲述Elasticsearch批量更新索引指定字段操作
|
12月前
|
机器学习/深度学习 自然语言处理 监控
命名实体识别(Named Entity Recognition, NER)
命名实体识别(NER)是自然语言处理的重要任务,旨在从文本中识别并分类特定实体,如人名、地点、组织等。通过BIO等标注模式,利用HMM、CRF及深度学习模型如RNN、LSTM、Transformer等进行实体识别。预训练模型如BERT显著提升了NER的性能。NER广泛应用于新闻分析、生物医学等领域,是信息提取、知识图谱构建等任务的基础。
1509 3
|
机器学习/深度学习 计算机视觉
一文详解残差网络
残差网络(ResNet)源于2016年的论文《Deep Residual Learning for Image Recognition》,旨在解决深层网络中的梯度消失和爆炸问题。通过引入残差块,即在网络中添加跳跃连接,使得信息可以直接跨过多层传递,从而有效解决了网络加深导致的训练困难。ResNet不仅显著提高了模型性能,还促进了深度学习领域的发展。
1902 3
|
机器学习/深度学习 自然语言处理
预训练-微调范式
预训练-微调范式
|
机器学习/深度学习 数据采集 人工智能
深度学习在医疗影像分析中的应用与未来展望
深度学习技术近年来在医疗影像分析领域取得了显著进展,通过自动化处理和高度准确的诊断能力,极大地提升了疾病检测和治疗的效率。本文探讨了当前深度学习在医疗影像分析中的应用现状,具体案例,以及未来可能的发展方向和面临的挑战。
291 3