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