聚合(Aggregation):
这是一种松散的对象间的关系.举个例子:计算机和他的外围设备就是一例.
用来表示拥有关系或者整体与部分的关系。
组合(Composition):
这是一种非常强的对象间的关系,举个例子,树和它的树叶之间的关系.
在一个合成里,部分与整体的生命周期都是一样的。一个合成的新对象完全拥有对其组成部分的支配权。包括他们的创建和毁灭。
这两个非常的相似,
聚合:
• 聚合有时能够不依赖部分而存在,有时又不能
• 部分可以独立于聚合而存在
• 如果有一部分遗失,聚合会给人一种不完全的感觉
• 部分的所有权可以由几个聚合来共享,比如打印机
[通过接口设置]
组成:
• 部分某一时刻只能属于某一个组成
• 组成唯一的负责处理它的所有部分--这就意味着负责他们的创建与销毁
• 倘若对于部分的职责由其他对象来承担的话,组成也就可以放松这些职责。
• 如果组成销毁的话,它必须销毁所有的部分,或者把负责他们的权利转移给其他对象。
[通过代码组合]
模型驱动设计(Model-DrivenDesign)抛弃了分裂分析模型与设计的做法,使用单一的模型来满足这两方面的要求。这就是领域模型!
领域模型把分析和设计放在一起,单一的领域模型同时满足分析原型和软件设计,如果一个模型实现时不实用,重新寻找新模型。[只用单一的模型来满足分析与设计,不能满足就重新寻找模型]如何寻找模型?模型又是一个什么?
根据Eric的理论,业务层将细分为两个层次:应用层和领域层。
应用层:定义软件可以完成的工作,并且指挥具有丰富含义的领域对象来解决问题,保持精练;不包括业务规则或知识,无业务情况的状态;Action[这个代码更改的概率为0]
领域层:负责表示业务概念、业务状态的信息和业务规则,是业务软件核心。层次之间必须清晰分离,每个层都是内聚的,并且只依赖它的下层.[在领域 层会建立模型,比如用户模型,保存了用户的所有属性,用户所有的功能,全部面向接口,依赖下层实现,也就是以抽象的方式建立模型,就也就是在分析和设计的 时候设置的用户模型,比如以下类图]
分析与设计[设置顶级接口很重要]
用户顶级接口 User
Java代码
1. UserInfo getUserInfo() --得到用户信息:用户属性
2. void Speak() --说话:用户功能
3. void Walk() --走路:用户功能
看到这里会不会觉得用户接口很简单,很简洁.[爆露给外部调用的方法,在设计的时候已经确定]
用户接口的功能内聚,用户模型保存用户属性,所有功能面向接口,依赖下层实现.
接口抽象类 AbstratorUser
Java代码
1. UserInfo userInfo; --用户属性
2.
3. //用户操作对象.
4. Abstrator UserOperator getUserOperator() –用户操作对象信息,依赖下层
5.
6. //overwriter
7. Speak(){
8. getUserOperator ().Speak();
9. }
10.
11. //overwriter
12. Walk(){
13. getUserOperator ().Walk();
14. }
15. //用户信息在初始的时候留给子类设置
16. Void setUserInfo(UserInfo userInfo){
17. This.userInfo=userInfo
18. }
19.
20. //overwriter
21. UserInfo getUserInfo(){
22. Return userInfo;
23. }
[对业务逻辑的初步封装,蓝色部分是重写方法,而红色部分是需要依赖下层建筑的]
以上为设计阶段完成的,而下层建筑就交给开发工程师来完成,不同的开发工程师的水平和风格可能不一样,但是完全分离的方式使各模块[用户信息,用户操作]都能够正常运行,耦合为0. [这个代码更改的概率为0]
现在Action层代码更改为0,接口层和抽象层代码修改为0,那么当用户逻辑变的时候,只需要修改下层建筑就可以了!.
UserInfo为用户信息,这是一个实体类,其各对象的属性采用组合的方式来连接
Address,Account,Family.如果需要添加一些Friend等信息很方便,与其他模块不会有耦合.
UserOperator为用户操作对象,这是一个接口,依赖下层建筑.如果用户Speak的方式从中文变成英文了,只需要修改下层建筑就可以了.
这就是DDD,领域驱动开发,只依赖下层建筑,而下层建筑就是最简单的增删改查操作.也就是业务最需要变动的地方,领域驱动可以把一个项目分成一 个域,而这个域能够包含这个项目的所有信息,其实DDD并不算新的技术,他只是提供了一个概率,分析与设计的组合可以把业务逻辑理清,减少上层建筑的缺 陷,而下层建筑是可以随机换的,上层建筑一般是基本接口和抽象,只要业务逻辑没有分析出错,就不需要改动.而DDD把层分成两层,应用层和领域层,也是从 整体考虑,应用层调用领域层的接口,其实领域层也可以分层,他只是让系统的策划更简单,不用考虑那么多层,系统都是从简单到复杂,这相当于数据挖掘技术, 一张图很简单,再挖一下也很简单,再挖一下也很简单,应用不同的项目,不同的模块,基于接口和抽象的设计,并能从全局考虑就是DDD的思想.
现在来回答领域模型是什么:
领域模型是对领域内的概念类或现实世界中对象的可视化表示。
现实中的人 User
人的属性 getUserInfo()
人说话 Opertator.Speak()
人走路 Operator.Walk()
如何寻找模型:
在业务专家和设计专家一些交流的时候,设计专家能够从业务专家的描述中抽取出实体及实体间的关系[泛化、依赖和关联,关联又分了一般关联、聚合、组合等等]
分享到:
相关推荐
"领域模型"则是对这个领域的抽象表示,它包含了业务规则、业务实体、值对象、聚合、领域事件等关键元素。领域模型不仅仅是数据结构,更是业务行为的载体,它能够表达领域专家的思维,并在代码中实现这些业务规则。 ...
通过以上介绍,我们可以看到DDD领域模型设计方案是围绕业务领域进行的深度建模,旨在提高软件的业务契合度和灵活性。菱形对称架构则为这种建模提供了一个清晰的组织结构,帮助开发者更好地理解和管理复杂的系统。在...
1. **领域模型**:领域模型是DDD的核心,它是对业务领域的抽象表示,包含了业务规则和业务行为。在Java中,可以使用POJO(Plain Old Java Object)作为领域模型的基础,通过定义领域对象的属性和方法来表达业务逻辑...
DDD则侧重于设计范畴,它关注如何通过领域模型来组织和管理代码,使软件更好地反映业务逻辑。 软件开发的本质可以理解为将现实世界的问题转化为计算机世界的解决方案。在这个过程中,DDD提供了一种结构化的方法,...
DDD领域驱动设计到底是什么? DDD和传统三层优劣势比较 DDD在国内现象是个什么情况? DDD从战略设计到战术设计概览 第2章 领域分析模型 核心域,支撑子域,通用子域 微服务和DDD是什么关系? 传统模式下如何合理的...
DDD领域驱动设计&中台实践资料合集,共20份。 DDD促进传统架构微服务转型 化繁为简--DDD驱动复杂业务软件架构的演进 基于FP的DDD实践 基于DDD的领域建模中的模版和工具实践 架构分层模型适配 金融支付系统的改造之...
《.NET Core下的DDD领域模型项目详解》 在软件开发领域,领域驱动设计(Domain-Driven Design,简称DDD)是一种将业务逻辑与技术实现紧密结合的方法论。它强调以业务领域为中心,通过深入理解业务,构建复杂的软件...
【DDD领域建模】是软件开发中的一种高级设计方法,由Eric Evans在其2004年的著作《领域驱动设计——应对复杂软件的核心挑战》中提出。DDD的核心目标是通过深入理解业务领域,创建反映业务规则和流程的模型,以此来...
1. **领域模型**:领域模型是DDD的核心,它包含了业务领域的概念、规则和行为。通过领域模型,开发者可以清晰地表达业务逻辑,如实体(Entity)、值对象(Value Object)、聚合(Aggregate)、领域事件(Domain ...
- **分层架构**:例如采用CQRS模式,将领域模型置于应用层之下,命令处理时才涉及领域模型,查询和搜索则不走模型,通过tunnel层解耦模型与数据库。 5. **DDD 核心要素**: - **实体**:具有唯一标识,状态和生命...
- 第二天关注DDD实践篇,讲解如何基于领域模型进行数据库和程序设计,以及如何设计聚合、工厂和仓库。 - 第三天聚焦DDD架构篇,讨论如何构建支持领域驱动设计的技术中台和微服务架构,以及通过整洁架构支持技术架构...
领域驱动设计(DDD)是一种专注于复杂业务逻辑软件开发的方法论,它强调将业务领域知识和软件开发紧密结合起来,以实现对业务逻辑的深入理解和清晰表达。在当今互联网产品快速迭代的背景下,领域驱动设计显得尤为...
**基于DDD领域驱动设计通用后台权限系统开发** 领域驱动设计(Domain-Driven Design,简称DDD)是一种软件开发方法,强调以业务领域为中心进行系统设计,将复杂的业务逻辑转化为清晰的模型。在“基于DDD领域驱动...
以DDD思想为基础的轻量级业务中台开发框架 用状态机封装领域逻辑 在一个实际复杂业务中落地DDD方法与相关架构 DDD促进传统架构微服务转型 DDD的为与不为 DDD实践中的那些坑 DDD在旅游电商架构演进中的实践 Every ...
领域驱动设计(Domain-Driven Design,简称DDD)是一种软件开发方法论,它强调从业务领域出发进行软件设计,通过建立准确的领域模型来解决复杂业务问题。在DDD中,“模型提炼”是一个重要的环节,它涉及如何从复杂的...
DDD的核心思想是将软件开发聚焦于业务领域的复杂性,通过深入理解领域概念,建立领域模型,并在模型的基础上进行设计和开发。领域模型的设计实现过程通常涉及数据库设计、程序设计以及微服务设计。 领域驱动设计中...
《基于DDD领域驱动设计与CQRS命令查询职责分离的.NET Core框架详解》 在软件开发领域,领域驱动设计(Domain-Driven Design,简称DDD)和CQRS(Command Query Responsibility Segregation,命令查询职责分离)是两...
2. **领域模型**:对业务领域的抽象和表示,包括实体(Entities)、值对象(Value Objects)、聚合(Aggregates)、领域事件(Domain Events)等。 3. **实体**:具有唯一标识的对象,例如用户ID。 4. **值对象**:...
为了有效地实施DDD,需要领域专家(Domain Expert)与开发人员密切合作,共同构建和维护领域模型。领域专家负责定义业务规则和流程,而开发人员则负责将这些规则和流程转化为可执行的代码。通过这种方式,可以确保...
1. **领域模型**:领域模型是DDD的核心,它是一个包含业务规则、业务对象和业务行为的抽象模型。模型中的实体(Entity)、值对象(Value Object)、聚合(Aggregate)、领域事件(Domain Event)等元素共同构成了...