《领域驱动设计》的原文摘录
-
当人们学习设计技术时，各种可能性令他们兴奋不已，然而真实项目的错综复杂又会为他们泼一盆冷水 (查看原文)
-
当你遇到一个杂乱无章的大系统时，应该从哪里入手呢？在 XP 社区中，答案往往是以下之一：
1. 可以从任何地方开始，因为所有的东西都要重构；
2. 从影响你工作的那部分开始——也就是完成具体任务所需要的那个部分；
这两种做法我都不赞成。第一种做法并不可行，只有少数完全由顶尖的程序员组成的团队才是例外。第二种做法往往只是对外围问题进行了处理，只治标而不治本，回避了最严重的问题。最终这会使得代码变得越来越难以重构。
因此，如果你既不能全面解决问题，又不能“哪儿痛治哪儿”，那么该怎么办呢？
1. 如果采用“哪儿痛治哪儿”这种重构策略，要观察一下根源问题是否涉及 core domain 或 core 的支持元素的关系。如果确实涉及，那么就要接受挑战，首先修复核心。
2. 当可以自由选择重构的部分时，应首先集中精力把 core domain 更好地提取出来，完善对 core 的分离，并且把支持性德子领域提炼成通用子领域。
以上就是如何从重构中获取最大利益的方法。 (查看原文)
-
人们总是把软件开发比喻成制造业。这个比喻的一个推论是：经验丰富的工程师做设计工作，而技能水平较低的劳动力负责组装产品。这种做法使许多项目陷入困境，原因很简单——软件开发就是设计。 (查看原文)
-
由于应用层负责对领域对象的行为进行协调，因此细粒度的领域对象可能会把领域层的知识泄露到应用层中。这产生的结果是应用层不得不处理复杂的、细致的交互，从而使领域知识蔓延到应用层或用户界面代码中，而领域层会丢失这些知识。 (查看原文)
-
用户界面/展现层
负责向用户展现信息以及解释用户命令。
应用层
很薄的一层，用来协调应用的活动。它不包含业务逻辑。它不保留业务对象的状态，但它保有应用任务的进度状态。
领域层
本层包含关于领域的信息。这是业务软件的核心所在。在这里保留业务对象的状态，对业务对象和它们状态的持久化被委托给了基础设施层。
基础设施层
本层作为其他层的支撑库存在。它提供了层间的通信，实现对业务对象的持久化，包含对用户界面层的支撑库等作用。 (查看原文)
-
当开始编写软件的时候，其实我们所知甚少。 (查看原文)
-
高效率的团队，需要有意识地积累知识，并持续学习。 (查看原文)
-
如果文档的角色不太重要，那么总是将它更新为最新状态，将是劳动力的浪费。 (查看原文)
-
全体成员，应该使用统一、公共的领域模型语言，并找到更简单的表达方式，去说出要设计、实现的内容。
需求是随着项目的前景而演变的。 (查看原文)
-
UML使用不当，只是退化为程序本身的另一种视图，“模型”的真实含义就丢失了。 (查看原文)
-
如果正在创建的新系统与其他系统必须依靠一个大型的接口来连接，那么关联两个模型的难度可能最终会推翻新模型打算表现的意图，而是以一种特别的风格被修改成类似于另外那个系统的模型。老式系统的模型通常很弱，即使是精心开发的例外，也可能会不适合当前项目的需要。然而在集成中可能会有许多有价值的东西，而且有时候是绝对需要集成的。 (查看原文)
-
根据两个领域模型创建一个隔离层，为客户提供功能。该层可以通过现有接口与另外一个系统会话，而无需修改那个系统。在内部，该层进行两个模型之间必要的双向转换。 (查看原文)
-
声明一个与其他上下文根本没有任何连接的限界上下文，让开发人员在这个小范围内找出简单、专门的解决方案。
这种特性仍然可以组织在中间件或者 UI 层中，但是不存在逻辑共享，并且通过转换层的数据传输绝对最少，甚至没有。 (查看原文)
-
当子系统必须与大量的其他系统集成时，为每个系统定制一个转换器可能会让团队陷入困境。转换器越多，那么在作出改变时，需要担心的事情也越多。
定义一个协议，把你的子系统作为一组服务来使用。开放这个协议，让所有需要与您集成的人都能使用该协议。除非当一个团队有特殊需要时，否则，应该改进和扩充协议来满足新的集成需求。而为那种特殊情况使用一次性转换器来扩充该协议，从而可以保持公用协议的简单性和一致性。 (查看原文)
-
纯粹的分析模型甚至无法实现理解领域这一主要目的，因为在程序设计和实现过程中总是会发现一些关键的知识点，而细节问题则会出人意料地层出不穷。前期模型可能会忽略一些重要的问题，却深入研究另一些不相关的问题，而且它对于其他问题的描述也可能对应用程序没有任何帮助。最后的结果就是，在编码工作开始后纯粹的分析模型被抛弃，大部分的模型都需要重新设计。即便是重新设计，如果开发人员认为分析与程序开发毫不相关，那么建模过程就不会那么规范。而如果项目经理也这么认为，那么开发团队可能没有足够的机会与领域专家进行交流。 (查看原文)
-
当我们的建模不再局限于寻找实体和值对象时，我们才能充分吸取知识，因为业务规则之间可能会存在不一致。领域专家在反复研究所有规则、解决规则之间的矛盾以及常识来弥补规则的不足等一系列工作中，往往不会意识到她们的思考过程有多么复杂。 (查看原文)
-
尽管存在所有这些细节，但属性和关系只是对象模型的一部分。这些对象的行为以及这些对象上的约束就不那么容易表示了。对象交互图可以阐明设计中的一些复杂之处，但却无法用这种方式来展示大量的交互，就是工作量太大了，既要制作图，还要学习这些图而且交互图也只能暗示出模型的目的。要想把约束和断言包括进来，需要在 UML 中使用文本。
操作名称可能会暗示出对象的行为职责，对象交互图中也会隐含地展示出这些职责，但无法直接表述。
如果确实能使用 UML 这样的绘图语言来编写可执行程序，那么 UML 图就会退化为程序本身的另一种视图，这样，“模型” 的真正含义就丢失了。
图是一种沟通和解释手段，它们可以促进头脑风暴。简洁的小图能够很好地实现这些目标，而涵盖整个对象模型的综合性大图反而失去了沟通或解释能力
设计的重要细节应该在代码中体现出来。良好的实现应该是透明的，清楚地展示其背后的模型。 (查看原文)
-
改善模型的最佳方式之一就是通过对话来研究，试着大声说出可能的模型变化中的各种结构。这样不完善的地方很容易被听出来。
事实上，我们的大脑似乎很擅长处理口语的复杂性。例如，当具有不同语言背景的人凑在一起做生意时，如果没有公共语言，他们就会创造一种称为“混杂语”的公共语言。混杂语虽然不想讲话者的母语那样详尽，但它适合当前任务。 (查看原文)
-
尽可能地对关系进行约束是非常重要的。双向关联意味着只有将这两个对象放在一起考虑才能理解它们。当应用程序不要求双向遍历时，可以指定一个遍历方向，以便减少相互依赖，并简化设计。 (查看原文)
-
所谓 Service，它强调的是与其他对象的关系。与 Entity 与 Value Object 不同，它只是定义了能够为客户做什么，Service 往往是以一个活动来命名，而不是以一个 Entity 来命名。
好的 Service 有以下三个特征：
- 与领域概念相关的操作不是 Entity 或 Value Object 的一个自然组成部分。
- 接口是根据领域模型的其他元素定义的。
- 操作是无状态的。 (查看原文)
