DDD领域模型开发

聚合(Aggregation):
     这是一种松散的对象间的关系.举个例子:计算机和他的外围设备就是一例.
     用来表示拥有关系或者整体与部分的关系。
组合(Composition):
这是一种非常强的对象间的关系,举个例子,树和它的树叶之间的关系.
在一个合成里,部分与整体的生命周期都是一样的。一个合成的新对象完全拥有对其组成部分的支配权。包括他们的创建和毁灭。

这两个非常的相似,
聚合:
• 聚合有时能够不依赖部分而存在,有时又不能
• 部分可以独立于聚合而存在
• 如果有一部分遗失,聚合会给人一种不完全的感觉
• 部分的所有权可以由几个聚合来共享,比如打印机
[通过接口设置]
组成:
• 部分某一时刻只能属于某一个组成
• 组成唯一的负责处理它的所有部分--这就意味着负责他们的创建与销毁
• 倘若对于部分的职责由其他对象来承担的话,组成也就可以放松这些职责。
• 如果组成销毁的话,它必须销毁所有的部分,或者把负责他们的权利转移给其他对象。
[通过代码组合]

模型驱动设计(Model-DrivenDesign)抛弃了分裂分析模型与设计的做法,使用单一的模型来满足这两方面的要求。这就是领域模型!

领域模型把分析和设计放在一起,单一的领域模型同时满足分析原型和软件设计,如果一个模型实现时不实用,重新寻找新模型。[只用单一的模型来满足分析与设计,不能满足就重新寻找模型]如何寻找模型?模型又是一个什么?
根据Eric的理论,业务层将细分为两个层次:应用层和领域层。

应用层:定义软件可以完成的工作,并且指挥具有丰富含义的领域对象来解决问题,保持精练;不包括业务规则或知识,无业务情况的状态;Action[这个代码更改的概率为0]

领域层:负责表示业务概念、业务状态的信息和业务规则,是业务软件核心。层次之间必须清晰分离,每个层都是内聚的,并且只依赖它的下层.[在领域层会建立模型,比如用户模型,保存了用户的所有属性,用户所有的功能,全部面向接口,依赖下层实现,也就是以抽象的方式建立模型,就也就是在分析和设计的时候设置的用户模型,比如以下类图]


分析与设计[设置顶级接口很重要]
用户顶级接口 User
UserInfo  getUserInfo()  --得到用户信息:用户属性 
void Speak()       --说话:用户功能
void Walk()        --走路:用户功能

         
看到这里会不会觉得用户接口很简单,很简洁.[爆露给外部调用的方法,在设计的时候已经确定]

用户接口的功能内聚,用户模型保存用户属性,所有功能面向接口,依赖下层实现.
接口抽象类 AbstratorUser
UserInfo userInfo;    --用户属性

//用户操作对象.
Abstrator UserOperator getUserOperator() –用户操作对象信息,依赖下层

//overwriter
Speak(){
             getUserOperator ().Speak();
}

//overwriter
Walk(){
			getUserOperator ().Walk();
}
//用户信息在初始的时候留给子类设置
Void setUserInfo(UserInfo userInfo){
  This.userInfo=userInfo
}

//overwriter
UserInfo getUserInfo(){
  Return userInfo;
}

[对业务逻辑的初步封装,蓝色部分是重写方法,而红色部分是需要依赖下层建筑的]

以上为设计阶段完成的,而下层建筑就交给开发工程师来完成,不同的开发工程师的水平和风格可能不一样,但是完全分离的方式使各模块[用户信息,用户操作]都能够正常运行,耦合为0. [这个代码更改的概率为0]

现在Action层代码更改为0,接口层和抽象层代码修改为0,那么当用户逻辑变的时候,只需要修改下层建筑就可以了!.

UserInfo为用户信息,这是一个实体类,其各对象的属性采用组合的方式来连接
Address,Account,Family.如果需要添加一些Friend等信息很方便,与其他模块不会有耦合.
UserOperator为用户操作对象,这是一个接口,依赖下层建筑.如果用户Speak的方式从中文变成英文了,只需要修改下层建筑就可以了.

这就是DDD,领域驱动开发,只依赖下层建筑,而下层建筑就是最简单的增删改查操作.也就是业务最需要变动的地方,领域驱动可以把一个项目分成一个域,而这个域能够包含这个项目的所有信息,其实DDD并不算新的技术,他只是提供了一个概率,分析与设计的组合可以把业务逻辑理清,减少上层建筑的缺陷,而下层建筑是可以随机换的,上层建筑一般是基本接口和抽象,只要业务逻辑没有分析出错,就不需要改动.而DDD把层分成两层,应用层和领域层,也是从整体考虑,应用层调用领域层的接口,其实领域层也可以分层,他只是让系统的策划更简单,不用考虑那么多层,系统都是从简单到复杂,这相当于数据挖掘技术,一张图很简单,再挖一下也很简单,再挖一下也很简单,应用不同的项目,不同的模块,基于接口和抽象的设计,并能从全局考虑就是DDD的思想.

现在来回答领域模型是什么:
领域模型是对领域内的概念类或现实世界中对象的可视化表示。
现实中的人                                    User
人的属性                                         getUserInfo()
人说话                                           Opertator.Speak()
人走路                                           Operator.Walk()
如何寻找模型:
在业务专家和设计专家一些交流的时候,设计专家能够从业务专家的描述中抽取出实体及实体间的关系[泛化、依赖和关联,关联又分了一般关联、聚合、组合等等]

你可能感兴趣的:(数据挖掘,领域模型)