方法论岂是那么好懂的

如果没有两年的编程经验，如果对设计一个新项目的逻辑分层、包结构没有疑问，那么就别看这书了...看不懂的。

本书讲的是一种应对复杂软件系统设计的思想，作者若没个十几年的编程功底，沉淀不了这种方法论，写不出这种书。

光看一遍是看不懂的，摘录一些点慢慢消化吧。

大多数成功的架构使用这种分层架构：

用户界面层（或表示层）：负责向用户（或计算机系统）显示信息和解释用户指令 应用层：定义软件要完成的任务，并且指挥表达领域概念的对象来解决问题。这一层所负责的工作对业务来说意义重大，也是与其他系统的应用层进行交互的必要渠道。应用层要尽量简单，不包含业务规则或者知识，而只为下一层中的领域对象协调任务、分配工作，使它们互相协作，它没有反映业务情况的状态，但是却可以具有另外一种状态，为用户或程序显示某个任务的进度。 领域层（或模型层）：负责表达业务概念、业务状态信息以及业务规则。尽管保存业务状态的技术细节是由基础设施层事先的，但是反映业务情况的状态是由本层控制并且使用的。领域层是业务软件的核心。 基础设施层：为上面各层提供通用的技术能力，为应用层传递消息，为领域层提供持久化机制，为用户界面层绘制屏幕组件等等。

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

Entity

实体的概念是一种贯穿整个生命周期（甚至会经历多种形式）的抽象的连续性。

一些对象主要不是由它们的属性定义的。它们实际上表示了一条“标识线”（A Thread of Identity），这条线跨越时间，而且常常经历多种不通的表示。

主要由标识定义的对象叫Entity。Entity（实体）有特殊的建模和设计思路，它们具有生命周期，这期间它们的形式和内容可能发生根本该表，但必须保持一种内在的连续性。为了有效地追踪这些对象，必须定义它们的标识。它们的类定义、职责、属性和关联必须由其标识来决定，而不依赖于其所具有的属性。Entity可以是任何事物，只要满足两个条件，一是它在整个生命周期中具有连续性，二是它的区别并不是由那些对用户非常重要的属性决定的。

Value Object

用于描述领域的某个方面而本身没有概念标识的对象称为Value Object（值对象）。Value Object应该是不可变的，被实例化之后用来表示一些设计元素，我们只关心它是什么，而不关心它是谁。Value Object经常作为参数在对象之间传递消息，它常常是临时对象，在一次操作中被创建，然后丢弃。