DDD领域驱动设计---入门书籍：第一部分：运用领域模型

最新推荐文章于 2024-08-15 10:17:05 发布

JJyu可及

最新推荐文章于 2024-08-15 10:17:05 发布

阅读量894

点赞数

分类专栏：研发管理 Java工程狮学习文章标签： DDD 领域驱动模型领域模型

本文链接：https://blog.csdn.net/jjy19971023/article/details/115257724

版权

Java工程狮学习同时被 2 个专栏收录

50 篇文章 1 订阅

订阅专栏

研发管理

48 篇文章 2 订阅

订阅专栏

DDD领域驱动设计——Domain Driven Design入门书籍

控制复杂性的关键是有一个好的领域模型，这个模型不应该仅仅停留在领域的表面，而是要透过表象抓住领域的实质结构，从而为软件开发人员提供他们所需的支持。

领域建模是一个参考框架是一种思维方式也是一组优先任务，它旨在加速那些必须处理复杂领域的软件项目的开发，用于解释相关活动，并用其来控制复杂性建立一个好的领域模型。领域模型最大的价值是其提供一种通用语言，这种语言可以将领域专家和技术人员联系在一起。

成功项目的共同特征：有一个丰富的领域模型，并且这个模型在迭代设计的过程中不断演变，并且成为项目不可分割的一部分。

项目的宏伟目标——交付了能够满足组织后续需求可以不断演进的复杂软件。

真正决定软件复杂性的是设计方法。

很多应用程序最主要的复杂性并不在技术上，而是来自领域本身、用户的活动或业务。当这种领域复杂性在设计中没有得到解决时，基础技术的构思再好也无济于事。成功的设计必须系统地考虑软件的这个核心方面。

第一部分：运用领域模型

模型：对现实的一种解释，把与解决问题密切相关的方面抽象出来，忽略无关的细节。

领域：用户应用软件的问题区域。

领域模型并非某种特殊的图，而是这种图所传达的思想。是对领域专家头脑中的知识严格的组织且有选择的抽象。

模型在领域驱动设计中的作用

模型和设计的核心相互影响

正是模型与实现之间的紧密联系才使模型变得有用，并确保我们在模型中所进行的分析能够转化为最终产品（即一个可运行的程序）。模型与实现之间的这种紧密结合在维护和后续开发期间也会很有用，因为我们可以基于对模型的理解来解释代码。
模型是团队所有成员使用的通用语言的中枢

由于模型与实现之间的关联，开发人员可以使用该语言来讨论程序。他们可以在无需翻译的情况下与领域专家进行沟通。而且，由于该语言是基于模型的，因此我们可借助自然语言对模型本身进行精化。
模型是浓缩的知识

模型是团队一致认同的领域知识的组织方式和重要元素的区分方式。透过我们如何选择术语、分解概念以及将概念联系起来，模型记录了我们看待领域的方式。当开发人员和领域专家在将信息组织为模型时，这一共同的语言（模型）能够促使他们高效地协作。模型与实现之间的紧密结合使来自软件早期版本的经验可以作为反馈应用到建模过程中。

软件的核心：是为用户解决领域相关问题的能力。

第一章消化知识

有效建模的要素

模型和实现绑定
建立一种基于模型的语言
开发一个蕴含丰富知识的模型
提炼模型
头脑风暴和实验

正是头脑风暴和大量实验的创造力才使我们找到了一个富含知识的模型并对它进行提炼，在这个过程中，基于模型的语言提供了很大帮助，而且贯穿整个实现过程中的反馈闭环也对模型起到了“训练”作用。这种知识消化将团队的知识转化为有价值的模型。

知识消化并非一项孤立的活动，它一般是在开发人员的领导下，由开发人员与领域专家组成的团队来共同协作。他们共同收集信息，并通过消化而将它组织为有用的形式。

高效率的团队需要有意识地积累知识，并持续学习。对于开发人员来说，这意味着既要完善技术知识，也要培养一般的领域建模技巧（如本书中所讲的那些技巧）。但这也包括认真学习他们正在从事的特定领域的知识。

领域专家在反复研究所有规则、解决规则之间的矛盾以及以常识来弥补规则的不足等一系列工作中，往往不会意识到他们的思考过程有多么复杂。软件是无法完成这一工作的。正是通过与软件专家紧密协作来消化知识的过程才使得规则得以澄清和充实，并消除规则之
间的矛盾以及删除一些无用规则。

更明确的设计具有以下优点：

为了实现更明确的设计，程序员和其他各位相关人员都必须理解超订的本质，明白它是一个明确且重要的业务规则，而不只是一个不起眼的计算。
程序员可以向业务专家展示技术工件，甚至是代码，但应该是领域专家（在程序员指导下）可以理解的，以便形成反馈闭环。

第二章交流与语言的使用

领域模型可成为软件项目通用语言的核心，该模型是一组得自于项目人员头脑中的概念，以及反映了领域深层含义的术语和关系。

这种基于模型的交流并不局限于UML（统一建模语言）图。为了最有效地使用模型，需要充分利用各种交流手段。基于模型的交流提高了书面文档的效用，也提高了敏捷过程中再度强调的非正式图表和交谈的效用。它还通过代码本身及对应的测试促进了交流。

Ubiquitous Language 通用语言的词汇包括类和主要操作的名称。语言中的术语，有些
用来讨论模型中已经明确的规则，还有一些则来自施加于模型上的高级组织原则。最后，团队常常应用于领域模型的模式名称也使这种语言更为丰富。

模型之间的关系成为所有语言都具有的组合规则。词和短语的意义反映了模型的语义。

开发人员应该使用基于模型的语言来描述系统中的工件、任务和功能。这个模型应该为开发人员和领域专家提供一种用于相互交流的语言，而且领域专家还应该使用这种语言来讨论需求、开发计划和特性。语言使用得越普遍，理解进行得就越顺畅。

模型

将模型作为语言的支柱。确保团队在内部的所有交流中以及代码中坚持使用这种语言。在画图、写东西，特别是讲话时也要使用这种语言。
通过尝试不同的表示方法（它们反映了备选模型）来消除难点。然后重构代码，重新命名类、方法和模块，以便与新模型保持一致。解决交谈中的术语混淆问题，就像我们对普通词汇形成一致的理解一样。
要认识到， UBIQUITOUS LANGUAGE的更改就是对模型的更改。
领域专家应该抵制不合适或无法充分表达领域理解的术语或结构，开发人员应该密切关注那些将会妨碍设计的有歧义和不一致的地方

UBIQUITOUS LANGUAGE是那些以非代码形式呈现的设计的主要载体，这些包括把整个系统组织在一起的大尺度结构、定义了不同系统和模型之间关系的限界上下文，以及在模型和设计中使用的其他模式。讨论系统时要结合模型。使用模型元素及其交互来大声描述场景，并且按照模型允许的方式将各种概念结合到一起。找到更简单的表达方式来讲出你要讲的话，然后将这些新的想法应用到图和代码中。

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-eXfAYASt-1616774287086)(G:\研究方向\DDD领域驱动设计\photo\DDD入门书籍\image-20210326215843737.png)]$

UML图无法传达模型的两个最重要的方面，一个方面是模型所表示的概念的意义，另一方面是对象应该做哪些事情。图是一种沟通和解释手段，它们可以促进头脑风暴。

设计的重要细节应该在代码中体现出来。互为补充的图和文档能够引导人们将注意力放在核心要点上。自然语言的讨论可以填补含义上的细微差别。务必要记住模型不是图。图的目的是帮助表达和解释模型。

文档应作为代码和口头交流的补充

代码是行为明确的，但是并不意味着这些明确的行为背后的意义会被人们准确识别出来。

文档不应再重复表示代码已经明确表达出的内容。代码已经含有各个细节，它本身就是一种精确的程序行为说明。其他文档应该着重说明含义，以便使人们能够深入理解大尺度结构，并将注意力集中在核心元素上。当编程语言无法直接明了地实现概念时，文档可以澄清设计意图。

文档必须深入到各种项目活动中去。判断是否做到这一点的最简单方法，是观察文档与UBIQUITOUS LANGUAGE之间的交互。文档是用人们（当前）在项目上讲的语言编写的吗？它是用嵌入到代码中的语言编写的吗？

一段代码所产生的实际行为是不会改变的。但是，方法名称可能会有歧义、会产生误导或者因为已经过时而无法表示方法的本质含义。测试中的断言是严格的，但变量和代码组织方式所表达出来的意思未必严格。好的编程风格会尽力使这种联系直接化，但其仍然主要靠开发人员的自律。编码时需要一丝不苟的态度，只有这样才能编写出“言行全部正确”的代码。

代码必须基于在编写需求时所使用的统一语言。

DDD核心思想：在实现、设计和团队交流中使用同一个模型作为基础。

解释性模型提供了一定的自由度，可以专门为某个特殊主题定制一些表达力更强的风格。领域专家在一个领域中所使用的视觉隐喻通常呈现了更清晰的解释，这可以教给开发人员领域知识，同时使领域专家们的意见更一致。

UML图VS解释性模型

第三章绑定模型和实现

领域驱动设计要求一种不同的建模方法

如果整个程序设计或者其核心部分没有与领域模型相对应，那么这个模型就是没有价值的，软件的正确性也值得怀疑。同时，模型和设计功能之间过于复杂的对应关系也是难于理解的，在实际项目中，当设计改变时也无法维护这种关系。若分析与和设计之间产生严重分歧，那么在分析和设计活动中所获得的知识就无法彼此共享。

MODEL-DRIVEN DESIGN（模型驱动设计）不再将模型和程序设计分离开,而是寻找一种可以满足这两方面的单一模型.

模型和设计的绑定需要的是在分析和程序设计阶段都能发挥良好作用的模型。

软件系统各个部分的设计应该忠实地反映领域模型，以便体现出这二者之间的明确对应关系。我们应该反复检查并修改模型，以便软件可以更加自然地实现模型，即使想让模型反映出更深层次的领域概念时也应如此。我们需要的模型不但应该满足这两种需求，还应该能够支持健壮的UBIQUITOUS LANGUAGE（通用语言）。

从模型中获取用于程序设计和基本职责分配的术语。让程序代码成为模型的表达，代码的改变可能会是模型的改变。而其影响势必要波及接下来相应的项目活动。
完全依赖模型的实现通常需要支持建模范式的软件开发工具和语言，比如面向对象的编程。

程序员的角度来看，对象真实存在于内存中，它们与其他对象相互联系，它们被组织成类，并且通过消息传递来完成相应的行为。

软件开发就是设计.

如果编写代码的人员认为自己没必要对模型负责，或者不知道如何让模型为应用程序服务，那么这个模型就和程序没有任何关联。
如果开发人员没有意识到改变代码就意味着改变模型，那么他们对程序的重构不但不会增强模型的作用，反而还会削弱它的效果。
如果建模人员不参与到程序实现的过程中，那么对程序实现的约束就没有切身的感受，即使有，也会很快忘记。
如果分工阻断了设计人员与开发人员之间的协作，使他们无法转达实现MODEL-DRIVEN DESIGN的种种细节，那么经验丰富的设计人员则不能将自己的知识和技术传递给开发人员。

MODEL-DRIVEN DESIGN的两个基本要素（即模型要支持有效的实现并抽象出关键的领域知识）已经失去了一个，最终模型将变得不再实用。

任何参与建模的技术人员，不管在项目中的主要职责是什么，都必须花时间了解代码。任何负责修改代码的人员则必须学会用代码来表达模型。每一个开发人员都必须不同程度地参与模型讨论并且与领域专家保持联系。参与不同工作的人都必须有意识地通过UBIQUITOUS LANGUAGE与接触代码的人及时交换关于模型的想法。