BlogJava-『一只小蚂蚁』的专栏-随笔分类-DDD

DDD Notes Draft(continuing update)

Thomas — Sat, 30 Jun 2007 09:00:00 GMT

I'm reading Eric Evans's book: Domain-Driven Design: Tackling Complexity in the Heart of Software.
The page will record some notes about the book, they may be messy, confused.

2007/6/30
Domain-Driven Design

主要内容：
1. 隔离（Isolate）域
2. 实体、值对象、服务、模块（module）
3. 域对象的生命周期
4. Representing processes as domain objects
5. Creating functions free of side effects
6. 概述（Conceptual contours）
7. 单例类
8. 扩展规范
9. 应用分析模式
10. 关联设计模式到模型
11. 维持域的完整性
12. Formulating the domain vision statement
13. 选择重构目标
14. 职责层
15. 创建一个可插入性的组件（component）框架
16. Bringing together large-scale structures and bounded contexts
===========================================================================================
XP假设你可以经常地、快速地通过重构来改善设计
===========================================================================================
part1, DDD的目标、定义、意义（what）
part2, Model-Driven Design, best practices, OO domain model; 架起model和实践的桥梁；standard patterns, 术语 ->common language, all team members; 保持model和实现排成一行的各种判定；（which？！）
part3, 强调发现过程（how）
part4, 原理（why）
===========================================================================================
Part I: 让领域模型发挥作用（Putting the Domain Model to Work）
模型是简化，是抽象。
用户应用问题域到程序中，这就是软件中的“域”。有些域涉及现实世界，订票业务；有些域是无形的，帐户程序的域是钱和财务；软件“域”很少与计算机有关，偶有例外，代码控制系统的域是软件开发本身。
模型是工具，用来减少负担——与用户活动相关的。一个合适的模型，使信息变得容易理解，集中于问题上。
域模型不是一张特别的图，而是这张图试图传达的观点；不是仅仅在领域专家脑中的知识，而是对知识的严格组织和选择性的抽象；
域模型不是只需尽可能地“现实化”一个模型，甚至在一个有形的真实世界的事物的域中，我们的模型也是一个人造的创造。（来源于生活，虚构）
///////////////////////////////////////////////////////////////////////////////////////////
DDD中模型的功用
DDD中，三种基本用法决定一个模型的选择：
1. 模型和设计核心相互定形。
模型和实现的绑定，有利于模型相关联，确保基于它的分析能够应用到最终产品中，也有利于维护和持续开发。
2. 模型是所有项目成员的语言支柱。
因为模型和实现的绑定，开发者能够以这种语言谈论程序；因为这种语言基于模型，我们的自然语言能力能够转为提纯这个模型本身。
3. 模型是知识精粹。
模型是项目组商定的方式，这种方式用来结构化域知识和区分感兴趣的元素；
///////////////////////////////////////////////////////////////////////////////////////////
软件的核心
软件的核心是它有为用户解决域关联问题的能力。
///////////////////////////////////////////////////////////////////////////////////////////
Ch1. 消化知识（Crunching Knowledge）

2007/7/2
消除术语中的冲突和歧义、技术观点的不一致。
头脑风暴、提纯；提问、解释。
代码模型
//////////////////////////////////////////////////////////////////////////////////////////
有效建模的因素
1. 绑定模型和实现
通过不断地迭代
2. 培养一门基于模型的语言
便于双方（无理解偏差）的交流
3. 开发一个富知识模型
模型不是用来看看的，需要它做事！
4. 提纯模型
5. 头脑风暴、试验

2007/7/3
知识消化
高效的领域建模者是知识消化者。他们消化大量的信息并且探索与之关联的点滴，尝试组织一个个的idea、寻求使其容易理解的简单方式。（化抽象为具体）。提纯过程是对发现最与之相关的特殊知识的一个严格表达。
//////////////////////////////////////////////////////////////////////////////////////////
知识消化不是一个孤独的行为。开发者和领域专家互相合作。未加工的资料可以来自领域专家的想法、已有系统的使用者、老系统开发组的经验或者同一个领域的另外一个项目。它们来自于文档和大量的交流。
//////////////////////////////////////////////////////////////////////////////////////////
在老的瀑布开发方式中，业务专家和分析员交谈，然后分析员消化、抽象并且将结果传达给开发者。这种方式的失败在于缺乏反馈。分析员对模型创建全权负责，而这仅仅依靠来自业务专家的“输入”。他们没有机会向开发者学习或者从软件的早期版本获得经验。知识流向了一个方向，但是没有汇集。
//////////////////////////////////////////////////////////////////////////////////////////
另外一些项目使用迭代开发的方式，但是他们在建立知识时失败了，因为他们没有抽象。开发者到业务专家那里询问他们想要的功能，然后就回去构建它，紧接着他们向业务专家们展示结果并询问接下来需要做什么。如果开发者进行重构的话，或许他们能够在持续扩展中保持软件“干净”，但是如果开发者对“域”没有兴趣，那么他们将只学到这个应用程序什么应该做，而不知道背后的原理。这样的方式可以建造出可用的软件，但是这个项目将永远不能达到通过对老功能推论，扩展出新的强大功能的程度。

2007/7/4
好的开发者将自然地开始抽象和建立一个模型，以使其可以做更多的事情。但是如果这些只是出现在技术层面，而没有和领域专家合作，那么这些想法无疑是天真的。知识的缺乏，可以生产出完成基本任务的软件产品，但是缺少了与领域专家思考方式的深度联系。
//////////////////////////////////////////////////////////////////////////////////////////
项目组成员间的交互作用在所有成员一起消化这个模型时发生变化。对领域模型的不断提纯强迫开发者来学习他们正在参加的项目的重要原理，而不是机械地完成一个个功能。领域专家通常以被迫来提纯他们了解的本质的方式来精炼他们自己的理解，进而得以理解软件项目所需的概念的苛刻。（？）
//////////////////////////////////////////////////////////////////////////////////////////
所有的这些使项目组成员更加胜任知识消化。他们剔除无关的，改造模型成更加有用的形式。分析员和开发者的介入，使得它被干净地组织和抽象，因此它对实现起到了杠杆作用。由于领域专家的介入，这个模型反射出业务的深层知识。这些抽象是真实的业务原则。
//////////////////////////////////////////////////////////////////////////////////////////
由于模型的改进，它变成一个组织不断流过项目的信息的工具。这个模型着力于需求分析。它与编码和设计亲密接触。在一个有效力的循环中，它深化项目组成员的视线到领域中，使他们看得更加清楚、达到对模型更进一步地提炼。这些模型从来都不是完美的；他们不断进化，他们必须对理解领域有实践性、有帮助，为了使应用程序可以被简单地实现和理解，他们必须严格。

Thomas 2007-06-30 17:00 发表评论

领域模型学习笔记

Thomas — Mon, 25 Dec 2006 14:10:00 GMT

对“领域模型”有“忽如一夜春风来”的感觉，太多书籍在谈它。将学习心得记录下来，与大家分享。

什么是领域模型？
领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。

那什么是概念类呢？
概念类是思想、事物或对象。
这样的解释，仍然显得抽象。还是先看图吧！

（图一）
利用上图，我们可以从概念类的符号、内涵和外延三个方面来考虑。
符号：表示概念类的词语或图形。
内涵：概念类的定义。
外延：概念类所适用的一组示例。
对应于上图，我们使用符号Sale来表示购买交易事件的概念类；Sale的内涵可以陈述为“表示购买交易的事件，并且具有日期和时间”；Sale的外延为“世界上所有销售实例的集合”。

为什么要创建领域模型？
降低与OO建模之间的表示差异。
领域层软件类的名称要源于领域模型中的名称，以使对象具有源于领域的信息和职责。
打个比方，你可以用一长串0和1来表示“薪水册”，可是这种软件表示与我们脑中的薪水册领域模型之间存在巨大的差异，这将影响我们对软件的理解和修改。而OO建模则可以减小这一差异。

那又如何创建领域模型呢？
可以通过以下三个步骤：
一. 寻找概念类
二. 将其绘制为UML类图中的类
三. 添加关联和属性

如何找到概念类？
1）重用和修改现有的模型。
这是首要、最佳且最简单的办法。可以从已发布的领域模型和书籍中获得。
2）使用分类列表
示例：

（图二）
3）确定名词列表
在对领域的文本性描述中识别名词和名词短语，将其作为候选的概念类或属性。
缺点：自然语言的不精确性，不同名词短语可能表示同一概念类或属性，此外可能还有歧义。
建议与概念类分类列表一同使用。

在实践中，在发现概念类时，一般直接为其绘制UML类图。

常见错误：把应该是概念类的事物表示为属性。
准则：如果我们认为某概念类X不是现实世界中的数字或文本，那么X可能是概念类而不是属性。
考虑一下航空预定领域。destination应该作为Flight的属性，还是作为单独的概念类Airport?

（图三）
在现实世界里，目的地机场不会被看作是数字或文本，而是一占据大规模空间的事物。因此，Airport应该是个概念，而不是属性。

描述类包含描述其他事物的信息。例如，ProductDescription记录Item的价格、图片和文字描述。
为什么使用描述类？
假设：雀巢咖啡，大受欢迎，销售一空。这就意味着雀巢咖啡的所有Item实例都从计算机存储器中被删除。这时如果有人问：雀巢咖啡多少钱一盒？那将没法回答。因为价格是记录在实例上的，而这些实例都已经被删除。由此可以看出，需要其他事物来记录雀巢咖啡的描述（规格说明）。

（图四）
何时需要？
1. 需要有关商品或服务的描述，独立于任何商品或服务的现有实例。
2. 删除其所描述事物（如Item）的实例后，导致信息丢失，而这些信息是需要维护的，但是被错误地与所删除的事物关联起来。
3. 减少冗余或重复信息。

关联
什么是关联？
关联是类（类的实例）之间的关系，表示有意义和值得关注的连接。

（图五）
何时表示关联？
1. 如果存在需要保持一段时间的关系，将这种语义表示为关联（“需要记住”的关联）。
2. 从常见关联列表中派生的关联。

准则：要避免在领域模型中加入太多的关联。

在领域建模过程中，关联不是关于数据流、数据库外键联系、实例变量或软件方案中的对象连接的语句；关联声明的是针对现实领域从纯概念角度看有意义的关系。

在UML中如何对关联命名？
以“类名－动词短语－类名”的格式为关联命名，其中的动词短语构成了可读的和有意义的顺序。
图五对应于：VideoStore Stocks Video

多重性定义了类A有多少个实例可以和类B的一个实例关联。（见图五）
多重性的值表示在特定时刻（而不是在某个时间跨度内）有效关联的实例数量。

（图六）

多重性是和语境有关的。

两个类之间的多重关联：

（图七）

常见关联列表：

（图八）

属性
什么是属性？
属性是对象的逻辑数据值。

何时展示属性？
当需求（例如，用例）建议或暗示需要记住信息时，引入属性。

（图九）
导出属性（derived attribute）：可以由其他信息导出的属性。

准则：大部分属性类型应该是“简单”数据类型，例如数字和布尔。通常，属性的类型不应该是复杂的领域概念，例如Sale或AirPort。

准则：领域模型中属性的类型更应该是数据类型。

准则：通过关联而不是属性来表示概念类之间的关系。

（图十）

领域模型是概念透视图，不是软件透视图。在设计模型中，属性可以是任何类型。

准则：任何属性都不表示外键。

（图十一）

结论：
没有所谓唯一正确的领域模型。所有模型都是对我们试图要理解的领域的近似。领域模型主要是在特定群体中用于理解和沟通的工具。有效的领域模型捕获了当前需求语境下的本质抽象和理解领域所需要的信息，并且可以帮助人们理解领域的概念、术语和关系。

参考资料：
1. 《UML和模式应用》（第三版）

Thomas 2006-12-25 22:10 发表评论