《领域驱动设计-软件核心复杂性应对之道》笔记

问题：

1、  何为领域驱动设计（DOMAINDriven DESIGN）？

2、  UBIQUITOUS LANGUAGE（领域通用语言）应该是如何去描述

3、   

 

 作者：Eric Evans

第二部分 模型驱动设计的构造块

第四章 分离模型

分层架构如图：

而主要的业务模型及在领域层。

第五章 软件中所表示的模型

模型主要包括Entity、Value Object和service

问题：

Entity、Value Object和Service是如何定义的？

它们是如何进行区分和划分的？

ENTITY

Entity模型具有标识的，模型必须定义出：“符合什么条件才算是相同的事务”。

要求：保持实体的简练、不要将注意力集中在属性或行为上，应该摆脱这些细枝末节

VALUE OBJECT

当我们只关心一个模型元素的属性时，应该将其归类到value object中。我们应该使这个模型元素表示出属性的意义，并为它提供相关功能。Value object应该是不可变的。不要为它分配任何标识，而且不要把它弄的和entity一样复杂。

在考虑到分布式环境中时：value object的两种方式应该如何适用，两个方式是复制和共享，都分别的特点是什么呢?

SERVICE

好的Service有以下三个特征：

1、  与领域概念相关的操作不是entity或value object的一个自然的部分

2、  接口是根据领域模型的其他元素定义的

3、  操作时无状态的（无状态指可以使用某个service的任何实例）。

当领域中的摸个重要的过程或转换操作不属于实体或值对象的自然职责时，应该在模型中添加一个作为独立接口的操作，并将其声明为service。定义接口时要使用模型语言，并确保操作名称是ubiquitous language中的术语。此外，应该将service定义为无状态的。

第六章 领域对象的生命周期

模式：Aggregate

每个对象模型都应该找到它的聚合根，其他仅对该模型有效的应通过聚合根来得到而不应该直接访问该对象