The page will record some notes about the book, they may be messy, confused.
2007/6/30
Domain-Driven Design
主要内容Q?br>1. 隔离QIsolateQ域
2. 实体、值对象、服务、模块（moduleQ?br>3. 域对象的生命周期
4. Representing processes as domain objects
5. Creating functions free of side effects
6. 概述QConceptual contoursQ?br>7. 单例c?br>8. 扩展规范
9. 应用分析模式
10. 兌设计模式到模?br>11. l持域的完整?br>12. Formulating the domain vision statement
13. 选择重构目标
14. 职责?br>15. 创徏一个可插入性的lgQcomponentQ框?br>16. Bringing together large-scale structures and bounded contexts
===========================================================================================
XP假设你可以经常地、快速地通过重构来改善设?br>===========================================================================================
part1, DDD的目标、定义、意义（whatQ?br>part2, Model-Driven Design, best practices, OO domain model; 架vmodel和实늚桥梁Qstandard patterns, 术语 ->common language, all team members; 保持model和实现排成一行的各种判定Q（whichQ！Q?br>part3, 发现q程QhowQ?br>part4, 原理QwhyQ?br>===========================================================================================
Part I: 让领域模型发挥作用（Putting the Domain Model to WorkQ?br>模型是简化，是抽象?br>用户应用问题域到E序中，q就是Y件中?#8220;?#8221;。有些域涉及现实世界Q订业务；有些域是无Ş的，帐户E序的域是钱和胦务；软g“?#8221;很少与计机有关Q偶有例外，代码控制pȝ的域是Y件开发本w?br>模型是工P用来减少负担——与用户zd相关的。一个合适的模型Q信息变得Ҏ理解Q集中于问题上?br>域模型不是一张特别的图，而是q张图试图传辄观点Q不是仅仅在领域专家脑中的知识，而是对知识的严格l织和选择性的抽象Q?br>域模型不是只需可能地“现实?#8221;一个模型，甚至在一个有形的真实世界的事物的域中Q我们的模型也是一个h造的创造。（来源于生z，虚构Q?br>///////////////////////////////////////////////////////////////////////////////////////////
DDD中模型的功用
DDD中，三种基本用法军_一个模型的选择Q?br>1. 模型和设计核心相互定形?br>模型和实现的l定Q有利于模型相关联，保Z它的分析能够应用到最l品中Q也有利于维护和持箋开发?br>2. 模型是所有项目成员的语言支柱?br>因ؓ模型和实现的l定Q开发者能够以q种语言谈论E序Q因U语aZ模型Q我们的自然语言能力能够转ؓ提纯q个模型本n?br>3. 模型是知识精_V?br>模型是项目组商定的方式，q种方式用来l构化域知识和区分感兴趣的元素；
///////////////////////////////////////////////////////////////////////////////////////////
软g的核?br>软g的核心是它有为用戯军_兌问题的能力?br>///////////////////////////////////////////////////////////////////////////////////////////
Ch1. 消化知识QCrunching KnowledgeQ?br>
2007/7/2
消除术语中的冲突和歧义、技术观点的不一致?br>头脑风暴、提U；提问、解释?br>代码模型
//////////////////////////////////////////////////////////////////////////////////////////
有效建模的因?br>1. l定模型和实?br>通过不断地P?br>2. 培养一门基于模型的语言
便于双方Q无理解偏差Q的交流
3. 开发一个富知识模型
模型不是用来看看的，需要它做事Q?br>4. 提纯模型
5. 头脑风暴、试?br>
2007/7/3
知识消化
高效的领域徏模者是知识消化者。他们消化大量的信息q且探烦与之兌的点_试l织一个个的idea、寻求其容易理解的单方式。（化抽象ؓ具体Q。提U过E是对发现最与之相关的特D知识的一个严D达?br>//////////////////////////////////////////////////////////////////////////////////////////
知识消化不是一个孤独的行ؓ。开发者和领域专家互相合作。未加工的资料可以来自领域专家的x、已有系l的使用者、老系l开发组的经验或者同一个领域的另外一个项目。它们来自于文和大量的交流?br>//////////////////////////////////////////////////////////////////////////////////////////
在老的瀑布开发方式中Q业务专家和分析员交谈，然后分析员消化、抽象ƈ且将l果传达l开发者。这U方式的p|在于~Z反馈。分析员Ҏ型创建全权负责，而这仅仅依靠来自业务专家?#8220;输入”。他们没有机会向开发者学习或者从软g的早期版本获得经验。知识流向了一个方向，但是没有汇集?br>//////////////////////////////////////////////////////////////////////////////////////////
另外一些项目用P代开发的方式Q但是他们在建立知识时失败了Q因Z们没有抽象。开发者到业务专家那里询问他们惌的功能，然后回L建它Q紧接着他们向业务专家们展示l果q询问接下来需要做什么。如果开发者进行重构的话，或许他们能够在持l扩展中保持软g“q净”Q但是如果开发者对“?#8221;没有兴趣Q那么他们将只学到这个应用程序什么应该做Q而不知道背后的原理。这L方式可以建造出可用的YӞ但是q个目永q不能达到通过对老功能推论，扩展出新的强大功能的E度?br>
2007/7/4
好的开发者将自然地开始抽象和建立一个模型，以其可以做更多的事情。但是如果这些只是出现在技术层面，而没有和领域专家合作Q那么这些想法无疑是天真的。知识的~ZQ可以生产出完成基本d的Y件品，但是~少了与领域专家思考方式的深度联系?br>//////////////////////////////////////////////////////////////////////////////////////////
目l成员间的交互作用在所有成员一h化这个模型时发生变化。对领域模型的不断提U强q开发者来学习他们正在参加的项目的重要原理Q而不是机械地完成一个个功能。领域专安常以被q来提纯他们了解的本质的方式来精g们自q理解Q进而得以理解Y仉目所需的概늚苛刻。（Q）
//////////////////////////////////////////////////////////////////////////////////////////
所有的q些佉K目组成员更加胜Q知识消化。他们剔除无关的Q改造模型成更加有用的Ş式。分析员和开发者的介入Q得它被干净地组l和抽象Q因此它对实现vC杠杆作用。由于领域专家的介入Q这个模型反出业务的深层知识。这些抽象是真实的业务原则?br>//////////////////////////////////////////////////////////////////////////////////////////
׃模型的改q，它变成一个组l不断流q项目的信息的工兗这个模型着力于需求分析。它与编码和设计亲密接触。在一个有效力的@环中Q它深化目l成员的视线到领域中Q他们看得更加清楚、达到对模型更进一步地提炼。这些模型从来都不是完美的；他们不断q化Q他们必d理解领域有实跉|、有帮助Qؓ了应用E序可以被简单地实现和理解，他们必须严格?br>
]]>
什么是领域模型Q?br>领域模型是对领域内的概念c?/strong>或现实世界中对象的可视化表示。又U?strong>概念模型?strong>领域对象模型?strong>分析对象模型?br>
?strong>什么是概念c?/strong>呢？
概念cL思想、事物或对象?br>q样的解释，仍然昑־抽象。还是先看图吧！
Q图一Q?br>利用上图Q我们可以从概念c?/strong>?strong>W号?strong>内涵?strong>外g三个斚w来考虑?br>W号Q表C概늱的词语或囑Ş?br>内涵Q概늱的定义?br>外gQ概늱所适用的一l示例?br>对应于上图，我们使用W号Sale?strong>表示购买交易事g的概늱QSale的内涵可以陈qCؓ“表示购买交易的事Ӟq且h日期和时?/strong>”QSale的外延ؓ“世界上所有销售实例的集合”?br>
Z么要创徏领域模型Q?br>降低与OO建模之间的表C差?/font>?br>领域层Y件类的名U要源于领域模型中的名称Q以使对象具有源于领域的信息和职责?br>打个比方Q你可以用一长串0?来表C?#8220;薪水?#8221;Q可是这UY件表CZ我们脑中的薪水册领域模型之间存在巨大的差异，q将影响我们对Y件的理解和修攏V而OO建模则可以减这一差异?br>
那又如何创徏领域模型呢？
可以通过以下三个步骤Q?br>一. L概念c?br>? 其l制为UMLcd中的c?br>? d兌和属?br>
如何扑ֈ概念c？
1Q重用和修改现有的模型?br>q是首要?strong>最?/strong>?strong>最?/strong>的办法。可以从已发布的领域模型和书c中获得?br>2Q用分cd?br>CZQ?br>
Q图二）
3Q确定名词列?br>在对领域的文本性描q?/strong>中识别名词和名词短语Q将其作为候选的概念cL属性?br>~点Q自然语a的不_性，不同名词短语可能表示同一概念cL属性，此外可能q有歧义?br>?strong>概念cdcd?/strong>一同用?br>
在实践中Q在发现概念cLQ一般直接ؓ?strong>l制UMLcd?br>
常见错误Q把应该是概늱的事物表CZؓ属性?br>准则Q?strong>如果我们认ؓ某概늱X不是现实世界中的数字或文本，那么X可能是概늱而不是属?/strong>?br>考虑一下航I预定领域。destination应该作ؓFlight的属性，q是作ؓ单独的概늱Airport?
Q图三）
在现实世界里Q目的地机场不会被看作是数字或文本，而是一占据大规模空间的事物。因此，Airport应该是个概念Q而不是属性?br>
描述c?/strong>包含描述其他事物的信息。例如，ProductDescription记录Item的h根{图片和文字描述?br>Z?/strong>使用描述c？
假设Q雀巢咖啡，大受Ƣ迎Q销售一I。这意味着雀巢咖啡的所有Item实例都从计算机存储器中被删除。这时如果有人问Q雀巢咖啡多钱一盒？那将没法回答。因Zh格是记录在实例上的，而这些实例都已经被删除。由此可以看出，需要其他事物来记录雀巢咖啡的描述Q规D明）?br>
Q图四）
何时需要？
1. 需要有兛_品或服务的描qͼ独立于Q何商品或服务的现有实例?br>2. 删除其所描述事物Q如ItemQ的实例后，D信息丢失Q而这些信息是需要维护的Q但是被错误C所删除的事物关联v来?br>3. 减少冗余或重复信息?br>
兌
什么是兌Q?br>兌是类Q类的实例）之间的关p，表示有意义和值得x的连接?br>
Q图五）
何时表示兌Q?br>1. 如果存在需要保持一D|间的关系Q将q种语义表示为关联（“需要记?#8221;的关联）?br>2. 从常见关联列表中z的关联?br>
准则Q?strong>要避免在领域模型中加入太多的兌?br>
在领域徏模过E中Q关联不是关于数据流、数据库外键联系、实例变量或软gҎ中的对象q接的语句；兌声明的是针对现实领域从纯概念角度看有意义的关pR?br>
在UML中如何对兌命名Q?br>?#8220;cdQ动词短语－cd”的格式ؓ兌命名Q其中的动词短语构成了可ȝ和有意义的顺序?br>图五对应于：VideoStore Stocks Video
多重?/strong>定义了类A有多个实例可以和类B的一个实例关联。（见图五）
多重性的?/strong>表示?strong>特定时刻Q而不是在某个旉跨度内）有效兌的实例数量?br>
Q图六）
多重性是和语境有关的?br>
两个cM间的多重兌Q?br>
Q图七）
常见兌列表Q?br>
Q图八）
属?br>什么是属性？
属性是对象的逻辑数据倹{?br>
何时展示属性？
当需求（例如Q用例）或暗C?strong>需要记?/strong>信息Ӟ引入属性?br>
Q图九）
导出属?/strong>Qderived attributeQ：可以由其他信息导出的属性?br>
准则Q?strong>大部分属性类型应该是“?#8221;数据cdQ例如数字和布尔。通常Q?strong>属性的cd不应该是复杂的领域概?/strong>Q例如Sale或AirPort?br>
准则Q?strong>领域模型中属性的cd更应该是数据cd?br>
准则Q?strong>通过兌而不是属性来表示概念cM间的关系?br>
Q图十）
领域模型是概念透视图，不是软g透视图。在设计模型中，属性可以是Mcd?br>
准则Q?strong>M属性都不表C外?/strong>?br>
Q图十一Q?br>
l论Q?br>没有所谓唯一正确的领域模型。所有模型都是对我们试图要理解的领域的近伹{领域模型主要是在特定群体中用于理解和沟通的工具。有效的领域模型捕获了当前需求语境下的本质抽象和理解领域所需要的信息Qƈ且可以帮助h们理解领域的概念、术语和关系?br>
参考资料：
1. 《UML和模式应用》（W三版）
]]>