理解你的领域
在启动一个软件项目时，我们应该关注软件设计的领域。软件的最终目的是增进一个特定的领域。为了达成这个目的，软件需要跟他要服务的领域和谐相处，否则,他会给领域引入麻烦。
如何才能让软件和领域和谐相处？最佳方式是让软件成为领域的反射(映射)。软件需要具体领域里重要的核心概念和元素，并精确的实现他们之间的关系。软件需要对领域进行建模。
image.png
领域驱动模型设计
分层架构
当我们创建一个软件应用时，这个应用的很大一部分是不能直接和领域相关联的。但他们是基础设施的一部分或者为软件服务的。最好让应用的领域部分尽量少的和其他部分掺杂在一起。
最好的方式将复杂的程序切分成层。开发每一层中内聚的设计，让每个层仅依赖它底下的那层。按照标准的架构模式以提供层的低耦合。将领域模型相关代码集中到一个层中。
- 展示层
负责向用户展示信息以及解释用户命令 - 应用层
用来协调应用的活动。它不包括业务的逻辑。不保留业务对象的状态，但它抱有应用任务的状态进度 - 领域层
是业务的核心逻辑，这里保留业务的状态，对业务对象和它们状态的持久化被委托给基础设施层 - 基础设施层
为其它层支撑所在，提供了层之间通信，实现对业务对象的持久化，包含对用户界面层的支撑库等作用。
实体(entity)
有一类对象看上去好像拥有标识符，它的标识符在经历软件的各种状态之后仍然保持一致。他们能够跨越生命周期，甚至超越软件系统的一系列的延续性和标识符。我们把这样的对象称为实体。
值对象(vo,dto等)
值对象
我们需要包含一个领域对象的
某些属性时。对这个对象是什么不感兴趣，只关心它拥有的属性。用来描述领域的特殊方面，并且没有标识符的对象称为值对象
如果值对象是可以共享的，那么它们应该是不可变的。值对象应该尽量保持简单，通常不会有什么副作用。
服务
当我们分析领域并试图将其构成模型主要对象时候，我们发现有些方面领域很难映射成对象。对象通常考虑拥有的属性，对象会管理它的内部的状态并暴露行为。但是领域中有些动作，他们是一些动词，看上去不属于任何对象。他们代表了领域中的一个重要的行为，我们无法忽略它或者简单的将他们合并到某个实体或者值对象中。
服务担当了一个提供操作的接口。服务再技术框架中是通用的，一个服务不是在执行服务的对象，而和被执行的操作对象相关。这样的情况下,一个服务通常变成了多个对象的一个连接点。这也是为什么行为很自然的依附于一个服务而不是被包含到其他领域对象的原因。
以下是服务3个特征
- 服务执行的操作涉及一个领域概念，这个领域概念通常不属于一个实体或者值对象
- 被执行的操作涉及领域中的其他对象
- 操作是无状态的
当领域中的一个重要的过程或者变化不属于一个实体或者值对象的自然职责时，向模型中增加一个操作，作为单独的接口将其声明一个service。根据领域模型的语言定义一个接口，确保操作的名字是通用语言的一部分，让服务边的无状态。
使用服务时保持领域层的隔离是非常重要的。很容易弄混属于领域层的服务和基础设施层的服务。
贫血模型
贫血领域对是指仅用于数据载体，而没有行为和动作的领域对象
习惯j2EE 开发模式，Action/Service/Dao的分层模式，很容易写出过程式的代码。使用这种的开发模式,对象只是数据的猜题，没有行为。以数据为中心，以数据库ER设计驱动。分层架构在这种开发模式下，可以理解为对数据的移动，处理和实现的过程。
业务领域中非常重要的逻辑都是封装在Service的方法中。复杂的业务逻辑场景下，业务逻辑状态会散落在大量的方法中，原来的代码意图会渐渐不明确
网友评论