您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
架构设计--领域设计
 
 
   次浏览      
 2021-6-1 
 
编辑推荐:
本文介绍了领域模型驱动设计模式、领域驱动设计的架构

以及“传统”架构-贫血领域模型。
本文来自于csdn,由火龙果软件Anna编辑、推荐。

架构设计变迁:

软件开发要干什么:

反映真实世界要自动化的业务流程

解决现实问题

领域Domain

Domain特指软件关注的领域

在不能充分了解业务领域的情况下是不可能做出一个好的软件

领域建模

领域模型驱动设计

分层架构

实体

值对象

服务

模块

聚合

工厂

资源库

分层架构:

将领域模型相关的代码集中到一个层中,把它从用户界面、应用和基础设施代码中分隔开来

释放领域对象的显示自己、保存自己、管理应用任务等职责,让它专注于展现领域模型

复杂的程序切分成层

层中采用内聚的设计

层仅依赖于它底下的那层

实体entity:

有一类对象拥有唯一标识符

能够跨越系统的生命周期甚至能超越软件系统的一系列的延续性和标识符

这样的对象称为实体。

值对象-value Object

对某个对象是什么不感兴趣,只关心它拥有的属性

用来描述领域的特殊方面、且没有标识符的一个对象,叫做值对象

能被简单的创建和丢弃,生命周期中不会被持久化

值对象可以被共享,值对象应该不可变

服务-service(比webservice更细粒度服务描述)

领域中的一些动词,代表了领域中的一个重要的行为,却不属于任何对象

服务执行的操作涉及一个领域概念,这个领域概念通常不属于一个实体或者值对象

被执行的操作涉及到领域中的其他的对象

操作是无状态的

服务对象不再拥有内置的状态

服务对象担当重要的协调功能

开发通用语言时,领域中的主要概念被引入到语言中,语言中的名词很容易被映射成对象。

语言中对应那些名词的动词变成那些对象的行为。但是有些领域中的动作,它们是一些动词,看上去却不属于任何对象。它们代表了领域中的一个重要的行为,所以不能忽略它们或者简单的把它们合并到某个实体或者值对象中。给一个对象增加这样的行为会破坏这个对象,让它看上去拥有了本该属于它的功能。

模块

将相关领域模型提炼分类,分而治之

将高关联度的模型分组到一个模块以提供尽可能大的内聚(以能完整完成任务为准)

分层是水平划分

模块是垂直划分(Domain内部)

参考架构概述

领域驱动设计(DomainDriven Design)有一个官方的sample工程,名为DDDSample

官网:http://dddsample.sourceforge.net/

该工程给出了一种实践领域驱动设计的参考架构

架构概述

详细架构

架构详解:Interfaces-接口层

该层包含与其他系统进行交互的接口与通信设施,在多数应用里

可能提供包括WebServices、RMI或Rest等在内的一种或多种通信接口

该层主要由Facade、DTO和Assembler三类组件构成,三类组件均是典型的J2EE模式

DTO

DTO- DataTransfer Object(数据传输对象),也常被称作VO-ValueObject(值对象)

DTO设计之初是为了将细粒度的领域对象包装为粗粒度的数据结构,减少网络通信并简化调用接口

DTO 作用

减少网络流量

简化远程对象和远程接口

传输更多的数据减少远程调用次数

避免将领域状态跨层次传递

由于同步和版本控制增加了复杂性

DTO 应用时序图

Assembler

DTO与领域对象之间的相互转换工作多由Assembler承担

因此Assembler几乎总是同DTO一起出现。

Assembler 实现方案

Facade

实践Facade的过程中最难把握的问题就是Facade的粒度问题。

传统的Service均以实体为单位进行组织,而Facade应该具有更粗粒度的组织依据,较为合适的粒度依据有:

一个高度内聚的模块一个Facade

或者是一个“聚合”(特指领域驱动设计)一个Facade.

Facade 实现方案

Facade 应用时序图

Service

Service会与多种组件进行交互

这些组件包括:

其他的Service

领域对象

Repository

DAO

Service 应用时序图

Domain-领域层

Domain层是整个系统的核心层,该层维护一个使用面向对象技术实现的领域模型,几乎全部的业务逻辑会在该层实现

Domain层包含:

Entity(实体)

ValueObject(值对象)

Domain Event(领域事件)

Repository(仓储)等

Infrastructure-基础设施层

基础设施层nfrastructure为Interfaces、Application和Domain三层提供支撑

所有与具体平台、框架相关的实现会在Infrastructure中提供,避免三层特别是Domain层掺杂进这些实现,从而“污染”领域模型

Infrastructure中最常见的一类设施是对象持久化的具体实现

“传统”架构-贫血领域模型

DDD && SOA

DDD 领域模型驱动设计

SOA 面向服务的架构

   
次浏览       
相关文章

为什么要做持续部署?
剖析“持续交付”:五个核心实践
集成与构建指南
持续集成工具的选择-装载
 
相关文档

持续集成介绍
使用Hudson持续集成
持续集成之-依赖管理
IPD集成产品开发管理
相关课程

配置管理、日构建与持续集成
软件架构设计方法、案例与实践
单元测试、重构及持续集成
基于Android的单元、性能测试
最新活动计划
LLM大模型应用与项目构建 12-26[特惠]
QT应用开发 11-21[线上]
C++高级编程 11-27[北京]
业务建模&领域驱动设计 11-15[北京]
用户研究与用户建模 11-21[北京]
SysML和EA进行系统设计建模 11-28[北京]
 
最新文章
iPerson的过程观:要 过程 or 结果
“以人为本”的工程哲学
企业架构、TOGAF与ArchiMate概览
UML 图解:顺序图( sequence diagram )
UML 图解:对象图( class diagram )
最新课程
基于UML和EA进行系统分析设计
UML+EA+面向对象分析设计
基于SysML和EA进行系统设计与建模
UML + 嵌入式系统分析设计
领域驱动的建模与设计
更多...   
成功案例
某电信运营供应商 应用UML进行面向对象分析
烽火通信 UML进行面向对象的分析设计
西门子 UML与嵌入式软件分析设计
航天科工某子公司 从系统到软件的分析、设计
深圳某汽车企业 模型驱动的分析设计
更多...