《领域驱动设计：软件核心复杂性应对之道（修订版）》

本节书摘来自异步社区《领域驱动设计：软件核心复杂性应对之道（修订版）》一书中的第2章，第2.3节一个团队，一种语言，作者【美】埃里克•埃文斯（Eric Evans）, 马利伟 , 万龙，更多章节内容可以访问云栖社区“异步社区”公众号查看。

2.3　一个团队，一种语言
技术人员通常认为业务专家最好不要接触领域模型，他们认为：

“领域模型对他们来说太抽象了。”

“他们不理解对象。”

32
“这样我们就不得不用他们的术语来收集需求。”

上面只列举了我从一个使用两种语言的团队中听到的少数几个原因。忘掉它们吧。

当然，设计中有一些技术组件与领域专家无关，但模型的核心最好让他们参与。过于抽象？那你怎么知道抽象是否合理？你是否像他们一样深入理解领域？有时，某些特定需求是从底层用户那里收集的，他们在描述这些需求时可能会用到一小部分更具体的术语，但领域专家应该能够更深入地思考他们所从事的领域。如果连经验丰富的领域专家都不能理解模型，那么模型一定出了什么问题。

最初，当用户讨论系统尚未建模的未来功能时，他们没有模型可供使用。但当他们开始与开发人员一起仔细讨论这些新想法时，探索共享模型的过程就开始了。最初的模型可能很笨拙且不完整，但会逐渐精化。随着新语言的演进，领域专家必须付出更多努力来适应它，并更新那些仍然很重要的旧文档。

当领域专家使用这种语言互相讨论，或者与开发人员进行讨论时，很快就会发现模型中哪些地方不符合他们的需要，甚至是错误的。另一方面，模型语言的精确性也会促使领域专家（在开发人员的帮助下）发现他们想法中的矛盾和含糊之处。

开发人员和领域专家可以通过一步一步地使用模型对象来走查场景，从而对模型进行非正式的测试。每次讨论都是开发人员和专家一起使用模型的机会，在这个过程中，他们可以加深彼此的理解，并对概念进行精化。

领域专家可以使用模型语言来编写用例，甚至可以直接利用模型来具体说明验收测试。

有时，有人会反对使用模型语言来收集需求。毕竟，难道需求不应该独立于实现它们的设计吗？这种观点忽视了所有语言都要基于某种模型这一事实。词的意义是不明确。领域模型通常是从领域专家自己的术语中推导出来的，但已经经过了“清理”，以便具有更明确、更严密的定义。当然，如果这些定义与领域公认的意义有较大差别，领域专家应该反对。在敏捷过程中，需求是随着项目的前进而演变的，因为几乎不存在现成的知识可以充分说明一个应用程序。用精化后的Ubiquitous Language来重新组织需求应该是这种演变过程的一部分。

33
语言的多样性通常是必要的，但领域专家与开发人员之间不应该有语言上的分歧（第12章将讨论多个模型在同一个项目上共存的情况）。

当然，开发人员的确会使用领域专家无法理解的技术术语。开发人员有其所需的大量术语来讨论系统技术。几乎可以肯定的是，用户也会用开发人员无法理解的、超出应用程序范畴的专用术语。这些都是对语言的扩展。但在这些语言扩展中，同一领域的相同词汇不应该反映不同的模型。

34
有了Ubiquitous Language之后，开发人员之间的对话、领域专家之间的讨论以及代码本身所表达的内容都基于同一种语言，都来自于一个共享的领域模型。

《领域驱动设计：软件核心复杂性应对之道（修订版）》—第2章 2.3节一个团队，一种语言...相关推荐

领域驱动设计:软件核心复杂性应对之道_人人都可以领域驱动设计（一）
最近几年,领域驱动设计(Domain-Driven Design,DDD)这个术语越来越多地出现在软件工程师的视野里.对DDD不熟悉的人可能会觉得它是软件领域里的一个新的概念,但是实际上,Eric E ...
解读《领域驱动设计软件核心复杂性应对之道》（一）
最近学习了两遍<领域驱动设计软件核心复杂性应对之道>.这本书是2000年出头由一个老外写的.然后经过了国人翻译. 2000年出头,技术架构还没有现在这么多好用的工具,也没有云原生的概念. ...
领域驱动设计软件核心复杂性应对之道_DDD - 领域驱动设计对软件复杂度的应对（上）...
不管是因为规模与结构制造的理解力障碍,还是因为变化带来的预测能力问题,最终的决定因素还是因为需求.Eric Evans 认为"很多应用程序最主要的复杂性并不在技术上,而是来自领域本身.用户的 ...
《领域驱动设计-软件核心复杂性应对之道》阅读笔记（二）
第二部分模型驱动设计的构造块第4章分离领域 4.1模式:LAYERED ARCHITECTURE 在面向对象的程序中,常常会在业务对象中直接写入用户界面.数据库访问等支持代码.而一些业务逻辑则会 ...
领域驱动设计_软件核心复杂性应对之道
领域驱动设计_软件核心复杂性应对之道转载于:https://www.cnblogs.com/MarvinGeng/archive/2013/02/21/2920968.html
《领域驱动设计：软件核心复杂性应对之道（修订版）》—第2章 2.1节模式：Ubiquitous Language...
本节书摘来自异步社区<领域驱动设计:软件核心复杂性应对之道(修订版)>一书中的第2章,第2.1节模式:Ubiquitous Language,作者[美]埃里克•埃文斯(Eric Evans ...
领域驱动设计：软件核心复杂性应对之道
http://vdisk.weibo.com/s/AbB5G02cEZ-Zo 转载于:https://www.cnblogs.com/dyh-air/p/7774955.html
DDD 洋葱架构才是 yyds！阿里大牛手记（DDD）领域驱动设计应对之道
虽然身为架构师,设计一个高质量的架构依然是复杂与困难的. 简单来说,动用大量的资源只为了一套优质的三高架构并不正确,而是该在了解当前业务现状的情况下,创造出灵活.可维护.健硕能成长的. 就拿近两年程序 ...
DDD洋葱架构才是 yyds，阿里架构师手记（DDD）领域驱动设计应对之道
虽然身为架构师,设计一个高质量的架构依然是复杂与困难的. 简单来说,动用大量的资源只为了一套优质的三高架构并不正确,而是该在了解当前业务现状的情况下,创造出灵活.可维护.健硕能成长的. 就拿近两年程序 ...
python 全栈开发，Day116(可迭代对象,type创建动态类,偏函数,面向对象的封装,获取外键数据,组合搜索,领域驱动设计(DDD))...
昨日内容回顾 1. 三个类 ChangeList,封装列表页面需要的所有数据.StarkConfig,生成URL和视图对应关系 + 默认配置 AdminSite,用于保存数据库类和处理该类的对象 ...

《领域驱动设计：软件核心复杂性应对之道（修订版）》—第2章 2.3节一个团队，一种语言...

《领域驱动设计：软件核心复杂性应对之道（修订版）》—第2章 2.3节一个团队，一种语言...相关推荐

最新文章

热门文章