(DDD看过后的一些要点...)
模型驱动设计的基本构成要素:
实体--值对象--服务--模块--聚合--工厂--资源库
实体:有一类对象看上去好像拥有标识符,它的标识符在经历软件的各种状态后仍能保持一致,对这些对象来讲这已经不再是它们关心的属性,这意味着能够跨越系统的生命周期甚至能超越软件系统的一系列的延续性和标识符.这样的对象称为实体.
值对象:用来描述领域的特殊方面,且没有标识符的一个对象,叫做值对象.
区分实体对象和值对象非常必要.选择那些符合实体定义的对象作为实体,将剩下的对象处理成值对象.这会简化设计,并且将会产生某些其他的积极的意义.
如果值对象是共享的,那么他妈应该是不可变的.值对象应该保持尽量的简单.
服务的3个特征:
1.服务执行的操作涉及一个领域概念,这个领域概念通常不属于一个实体或者值对象
2.被执行的操作涉及到领域重的其它的对象
3.操作是无状态的
1.服务执行的操作涉及一个领域概念,这个领域概念通常不属于一个实体或者值对象
2.被执行的操作涉及到领域重的其它的对象
3.操作是无状态的
模块:对一个大型的复杂项目而言,模型趋向于越来越大.模型到达了一个作为整体很难讨论的点,理解不同不见之间的关系和交互变得很困难.基于此原因,很有必要将模型组织进模块.模块被用来作为组织相关概念和任务以便降低复杂性的一种方法.
聚合是一个用来定义对象所有权和边界的领域模式.
工厂和资源库是另外的两个涉及模式,用来帮助我们处理对象的创建和存储问题.
工厂和资源库是另外的两个涉及模式,用来帮助我们处理对象的创建和存储问题.
工厂用来封装对象创建所必须的知识,它们对创建聚合特别有用.当聚合的根建立时,所有聚合包含的对象将随之建立,所有的不变量得到了强化.
将创建过程原子化非常重要,如果不这样做,创建过程就会存在对某个对象执行了一半操作的机会,将这些对象置于未定义的状态,对聚合而言更是如此.
将创建过程原子化非常重要,如果不这样做,创建过程就会存在对某个对象执行了一半操作的机会,将这些对象置于未定义的状态,对聚合而言更是如此.
代码设计应该围绕模型展开,模型自身也会基于设计决定而有所增进.脱离了模型的设计会导致软件不能反映它所服务的领域,甚至可能得不到期望的行为.建模如果得不到设计的反馈或者缺少了开发人员的参与,会导致必须实现模型的人很难理解它,并且可能对所用的技术不太适合.
建模的的一件事是阅读业务规范,从中寻找名词和动词.名词转换成类,而动词则成为方法.将产生前层次的模型.
