运用领域模型
文章目录
前言
每个软件程序是为了执行用户的某项活动，或是满足用户的某种需求。
为了创建真正能为用户活动所用的软件，开发团队必须运用一整套与这些活动有关的知识体系。
领域模型并非某种特殊的图，而是这种图所要传达的思想。
领域建模并不是要尽可能建立一个符合“现实”的模型。
在领域驱动的设计中，3个基本用途决定了模型的选择。
(1) 模型和设计的核心互相影响。
(2) 模型是团队所有成员使用的通用语言的中枢。
(3) 模型是浓缩的知识。
一、消化知识
1.1 有效建模的要素
(1) 模型和实现的绑定。
(2) 建立了一种基于模型的语言。
(3) 开发一个蕴含丰富知识的模型。
(4) 提炼模型。
(5) 头脑风暴和实验。
1.2 知识消化
高效的领域建模人员是知识的消化者。
知识消化并非一项孤立的活动，它一般是在开发人员的领导下，由开发人员与领域专家组成的团队来共同协作。
模型聚焦于需求分析。它与编程和设计紧密交互。
1.3 持续学习
高效率的团队需要有意识地积累知识，并持续学习。
那些善于自学的团队成员会成为团队的中坚力量，涉及最关键领域的开发任务要靠他们来攻克。
1.4 知识丰富的设计
更明确的设计具有以下优点：
(1) 为了实现更明确的设计，程序员和其他各位相关人员都必须理解超订的本质，明白它是一个明确且重要的业务规则，而不只是一个不起眼的计算。
(2) 程序员可以向业务专家展示技术工件，甚至是代码，但应该是领域专家（在程序员指导下）可以理解的，以便形成反馈闭环。
1.5 深层模型
有用的模型很少停留在表面。随着对领域和应用程序需求的理解逐步加深，我们往往会丢弃那些最初看起来很重要的表面元素，或者切换它们的角度。
二、交流与语言的使用
为了最有效地使用模型，需要充分利用各种交流手段。基于模型的交流提高了书面文档的效用，也提高了敏捷过程中再度强调的非正式图表和交谈的效用。
2.1 模式：UBIQUITOUS LANGUAGE
BIQUITOUS LANGUAGE（通用语言）的词汇包括类和主要操作的名称。将模型作为语言的支柱。确保团队在内部的所有交流中以及代码中坚持使用这种语言。解决交谈中的术语混淆问题，就像我们对普通词汇形成一致的理解一样。要认识到，UBIQUITOUS LANGUAGE的更改就是对模型的更改。领域专家应该抵制不合适或无法充分表达领域理解的术语或结构，开发人员应该密切关注那些将会妨碍设计的有歧义和不一致的地方。
2.2 “大声地”建模
讨论系统时要结合模型。使用模型元素及其交互来大声描述场景，并且按照模型允许的方式将各种概念结合到一起。找到更简单的表达方式来讲出你要讲的话，然后将这些新的想法应用到图和代码中。
2.3 一个团队，一种语言
语言的多样性通常是必要的，但领域专家与开发人员之间不应该有语言上的分歧
2.4 文档和图
图是一种沟通和解释手段，它们可以促进头脑风暴。
设计的重要细节应该在代码中体现出来。
互为补充的图和文档能够引导人们将注意力放在核心要点上。务必要记住模型不是图。图的目的是帮助表达和解释模型。
2.4.1 书面设计文档
文档应作为代码和口头交流的补充.
极限编程主张完全不使用（多余的）设计文档，而让代码解释自己。文档不应再重复表示代码已经明确表达出的内容。
设计文档的最大价值在于解释模型的概念，帮助在代码的细节中指引方向，或许还可以帮助人们深入了解模型预期的使用风格。
文档必须深入到各种项目活动中去。
2.4.2 完全依赖可执行代码的情况
尽管代码可能会产生误导，但它仍然比其他文档更基础。
2.5 解释性模型
解释性模型提供了一定的自由度，可以专门为某个特殊主题定制一些表达力更强的风格。
三、绑定模型和实现
3.1 模式：MODEL-DRIVEN DESIGN
如果整个程序设计或者其核心部分没有与领域模型相对应，那么这个模型就是没有价值的，软件的正确性也值得怀疑。同时，模型和设计功能之间过于复杂的对应关系也是难于理解的，在实际项目中，当设计改变时也无法维护这种关系。若分析与和设计之间产生严重分歧，那么在分析和设计活动中所获得的知识就无法彼此共享。
MODEL-DRIVEN DESIGN（模型驱动设计）不再将分析模型和程序设计分离开，而是寻求一种能够满足这两方面需求的单一模型。
软件系统各个部分的设计应该忠实地反映领域模型，以便体现出这二者之间的明确对应关系。
3.2 建模范式和工具支持
面向对象编程之所以功能强大，是因为它基于建模范式，并且为模型构造提供了实现方式。
3.3 揭示主旨：为什么模型对用户至关重要
如果程序设计基于一个能够反映出用户和领域专家所关心的基本问题的模型，那么与其他设计方式相比，这种设计可以将其主旨更明确地展示给用户。
3.4 模式：HANDS-ON MODELER
HANDS-ON MODELER（亲身实践的建模者）并不意味着团队成员不能有自己的专业角色。
任何参与建模的技术人员，不管在项目中的主要职责是什么，都必须花时间了解代码。任何负责修改代码的人员则必须学会用代码来表达模型。每一个开发人员都必须不同程度地参与模型讨论并且与领域专家保持联系。参与不同工作的人都必须有意识地通过UBIQUITOUS LANGUAGE与接触代码的人及时交换关于模型的想法。
将建模和编程过程完全分离是行不通的，然而大型项目依然需要技术负责人来协调高层次的设计和建模，并帮助做出最困难或最关键的决策。
总结
MODEL-DRIVEN DESIGN利用模型来为应用程序解决问题。项目组通过知识消化将大量杂乱无章的信息提炼成实用的模型。而MODEL-DRIVEN DESIGN 将 模 型 和 程 序 实 现 过 程 紧 密 结 合 。 UBIQUITOUSLANGUAGE则成为开发人员、领域专家和软件产品之间传递信息的渠道。
最终的软件产品能够在完全理解核心领域的基础上提供丰富的功能。如上所述，MODEL-DRIVEN DESIGN的成功离不开详尽的设计决策。
扫一扫
1214
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
