小湘西的博客

在领域驱动设计中，规格说明是一种强大的模式，用于封装业务规则，使得这些规则更加模块化和可维护。它通过提供清晰的业务规则界面，增强了业务逻辑的表达能力，并提高了代码的复用性和可测试性。规格说明的合理应用可以显著提升领域模型的清晰度和灵活性。

通过重构得到更深层的理解是一个涉及很多方面的过程。

分析模式是一种概念集合，用来表示业务建模中的常见结构。它可能只与一个领域有关，也可能跨越多个领域。。分析模式并不是技术解决方案，他们只是些参考，用来指导人们设计特定领域中的模型。分析模式的最大作用是借鉴其他项目的经验，把那些项目中有关设计方向和实现结果的广泛讨论与当前模型的理解结合起来。脱离具体的上下文来讨论模型思想不但难以落地，而且还会造成分析与设计严重脱节的风险，而这一点正是MODEL-DRIVEN DESIGN坚决反对的。

声明式设计风格是一种编程范式，它强调的是“做什么”（what）而不是“怎么做”（how）。释意接口是一种设计原则，要求接口的命名和设计应明确表达其用途和行为，以提高代码的可读性和可维护性。使用断言明确表示操作的副作用，包括后置条件（操作后的结果）和前置条件（操作前必须满足的条件）。声明式设计通过其高层次的抽象和对意图的清晰表达，提供了一种更简洁、可维护和易于理解的编程方式。这种设计方式强调了编写代码的目的或目标，而不是编写具体的指令来实现这些目标。声明式设计是一种编程范式，其中程序的逻辑表达为一系列声明，

如何为那些不明显的概念建模？1.显示的约束；2.将过程建模为领域对象；3.模式：规格（specifiction）

使用工厂（Factory）来创建和重建复杂对象和聚合，从而封装它们的内部结构。在生命周期的中间和末尾使用资源库（Repository）来提供查找和检索持久化对象。

是一个传统的，较成熟的设计元数，虽然使用模块有一些技术上的原因，但主要原因确是“认知超载”。它为我们提供了两种观察模式，一是可以在module中查看细节，而不会被整个模型淹没，二是观察module之间的关系，而不考虑内部细节。领域层中的module应该成为模型中有意义的部分，它从更大的角度描述了领域。1.Mudule的选择应该取决于被划分到模块中的对象的意义，它的名称应该来自通用语言。2.如果一个类依赖另一个包中的某个类，而且本地module对该module并没有概念上的依赖关系。

​资源库负责聚合对象的增删改查操作，目的是管理聚合的生命周期，严格来说，只有聚合才拥有资源库​

​聚合类是实体的升级，是由一组与生俱来就密切相关实体和值对象组合而成的，这整个组合的最上层实体就是聚合。Aggregate(聚合）是一组相关对象的集合，作为一个整体被外界访问，聚合根（Aggregate Root）是这个聚合的根节点。

​当领域中的某个操作过程或转换过程不是实体或值对象的职责时，便应该将该操作放在一个单独的接口中，即领域服务。是领域层的门面，外层不得跳过领域服务访问内部的领域对象或资源库。

值对象经常作为参数在对象之间传递消息。它们常常是临时对象，在一次操作中被创建，然后丢弃。它可用作实体（以及其他值对象）的属性。复制和共享，具体使用哪种方式取决于实现环境。虽然复制有可能导致系统被大量的对象阻塞，但是共享可能会减慢分布式系统的速度。在以下情况最好使用共享：这样可以发挥共享的最大价值并最大限度的减少麻烦。1.节省数据库空间或者减少对象数量是一个关键要求时。3.共享对象被严格要求限定为不可变时。

1.【识别属性】首先考虑实体的本质特征，尤其是那些用于识别（唯一标识）、查找或者匹配对象的特征。不要一开始就关注实体的属性和行为，只有在对实体的本质特征有用的情况下，才加入相应的属性和行为。每个实体是唯一的，并且可以相当长的一段时间内持续的变化。我们可以对实体做多次修改，故一个实体对象可能和他之前的状态大不相同，但是由于他们拥有相同的身份标识，他们依然是同一个实体。2.【挖掘行为】通过对实体相关所有用例的分析，整理出符合统一语言的实体的行为列表。2.它的区别并不是由那些对用户非常重要的属性决定的。

关联类型： 一对一、一对多 、多对多

Entity（实体）、Value Object（值对象）和Service（领域服务）

给复杂的应用程序划分层次。在每一层内分别进行设计，使其具有内聚性并且只依赖于他的下层。采用标准的架构模式，只与上层进行松散的耦合。将所有与领域相关的代码放在一个层中，并把他于用户界面层、应用层以及基础设施层的代码分开。领域对象应该将任务重点放在如何表达领域模型上，而不需要考虑自己的显示和存储的问题，也无需管理应用任务等内容。这使得模型的含义足够的丰富，结构足够清晰，可以捕捉到基本的业务知识，并有效的使用这些知识。

是与其他系统的应用层进行交互的必要渠道。应用层要尽量的简单，不包含业务规则或者知识，而只为下一层中的领域对象协调任务，分配工作。尽管保存业务状态的技术细节是由基础设施层实现，但是反应业务情况的状态是由本层控制并使用的。要想创建出能够处理复杂任务的程序，需要做到关注点分离---使设计中的每个部分都得到单独的关注。：为上面各层提供通用的技术能力：为应用层传递消息（MQ、事件等），为领域层提供持久化机制（资源库），为用户界面层提供汇总录屏组件。的基本原则是层中的任何元素都仅依赖于本层的其他元素或其下层的元素。

通过Repository 来访问资源，通过Aggregate来维护自身的完整性，Entity也是 Aggregate 的基础，通过Factory来封装自己。Aggregate(聚合）是一组相关对象的集合，作为一个整体被外界访问，聚合根（Aggregate Root）是这个聚合的根节点。通过Factory来封装自己。资源库负责聚合对象的增删改查操作，目的是管理聚合的生命周期，严格来说，只有聚合才拥有资源库。是实体的升级，是由一组与生俱来就密切相关实体和值对象组合而成的，这。

设计不再将分析模型和程序设计分离开，而是寻求一种能够满足这两方面需求的单一模型。这种单一模型不能够因为技术考虑而削弱分析能力，我们也不能接受那些只反应了领域概念却舍弃了软件设计原则的拙劣设计。模型驱动设计，关键就是消化领域知识并提炼出一个不错的核心模型。，并且用易于理解和易于表达的方式描述出来。

简洁的小图能够很好的实现这些目标，而涵盖了整个对象模型的综合性大图反而失去了沟通或者解释的能力。相反，应使用简化的图，图中只包含对象模型的重要概念--这些部分对于理解设计至关重要。所有人就对象关系会达成一致的知识，更重要的是他们将使用相同的对象名称。的时候大部分都是用UML图，主要是类图和对象交互为主。UML图在传达对象之间的关系上游刃有余，而且也很擅长表现交互。但当我们使用UML建模时对象的这些约束和断言很难通过UML体现出来，这时就需要在UML图中使用文本， 把这些文本用括号括起来，插入图中。

在讨论系统时要结合模型。使用模型元素及其交互来大声描述场景，并且按照模型允许的方式将各种概念结合到一起。找到更简单的表达方式来讲出你要讲的话，然后将这些新的想法应用到图和代码中。来源于业务术语（或者叫领域术语），那些显而易见的名词在编码时通常被用作对象的名称、行为被作为对象的方法、规则作为对象的约束或者对象间关系和交互。

通用语言是团队通用的、共享的语言

领域模型、领域建模

模型和实现直接建立链接、而且在所有的后续迭代中都要一直维护改链接。

模型是团队一致认同的领域知识的组织方式和重要元数的区分方式。透过我们如何选择术语、分解概念以及将概念联系起来，模型记录了我们看待领域的方式。当开发人员和领域专家在将信息组织为模型时，这一共同的语言（模型）能够促使他们高效的协助。由于模型与实现之间的关联，开发人员可以使用该语言来讨论程序，他可以在无需翻译的情况下与领域专家进行沟通。正是模型与现实之间的紧密联系才使得模型变得有用，并确保我们在模型中所进行的分析能够转换为最终产品（既可运行的程序）。

DDD中的一些概念：模型、领域、领域模型、领域建模