领域模型驱动设计(Domain Driven Design)入门概述

初探领域驱动设计(Domain Driven Design) 总结一下本篇文章的思路,我们先从DDD最基础的OOP面向对象入手,然后介绍了DDD的四层经典架构,接着阐述了DDD里面核心的领域实体和Repositoy还有领域服务这样的战术设计规范和方法,最后结合实际工作中遇到的场景来引出DDD战略设计的一些方法和思路。受制于笔者实践DDD的经验有限,虽然还有很多相关的内容本篇文章没有介绍,但是仍然想在这里抛出一个问题:什么时候?什么项目使用DDD比较合适?我相信在认真读了本篇文章并有自己一定实践经验的同学,能够给出自己的答案。 阅读详情

软件开发要干什么:

  • 反映真实世界要自动化的业务流程
  • 解决现实问题

领域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 实现方案


Façade


}  实践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  面向服务的架构

 

DDD领域模型设计 一、DDD领域模型设计概念 DDD的全称为Domain-driven Design,即领域驱动设计; 分层架构:UI层、应用层、领域层、基础设施层; User Interface 负责向用户展现信息,并且会解析用户行为,即常说的展现层。 Application Layer 应用层没有任何的业务逻辑代码,它很简单,它主要为程序提供任务处理。 Domain Layer 这一层包含有关领域的信息,是业务的核心,领域模型的状态都直接或间接(持久化至数据库)存储在这一层。 Infrastructure Layer 为 阅读详情

相关推荐

Oracle19c时区升级实战:从32到42版本的数据泵TSTZ报错解决方案

本文详细介绍了Oracle19c时区版本从32升级到42的实战步骤,重点解决数据泵TSTZ报错问题。通过检查时区版本、下载补丁包、应用补丁及执行升级脚本等关键操作,确保数据库时区数据更新,避免夏令时转换错误和历史时区规则不匹配等问题。文章还提供了常见问题排查和升级后的注意事项,帮助DBA高效完成时区升级任务。

n7o8p的博客 284

VO、DTO、DO、PO 概念及其区别

领域模型中的实体类分为四种模型:VO、DTO、DO、PO,各种实体类用于不同业务层次间的交互,并会在层次内实现实体类之间的转化。 VO (View Object)视图对象 用于展示层,它的作用是把某个指定页面(或组件)的所有数据封装起来。 DTO(Data Transfer Object)数据传输对象 主要用于展示层与服务层之间的数据传输对象 DO(Domain Object)领域对象 就是从现实世界中抽象出来的有形或无形的业务实体。 PO(Persistent Object):持久化对象 .

yunnuo的博客 1万+

西工大noj100题python2024第一季1-10

【代码】西工大noj100题python2024第一季1-10。

weixin_70523540的博客 1797

Domain Driven Design(领域驱动设计)

领域驱动设计(DDD) 强烈推荐文章:领域驱动设计(DDD); 术语: 建立领域知识(Build Domain Model) 限界上下文(Bounded Context) 通用语言(Ubiquitous Language) 模型关系图(Model-Driven Design) 层结构(Layered Architecture) DDD是什么 领域驱动设计(英语:Domain-driven design,缩写 DDD)是一种通过将实现连接到持续进化的模型来满足复杂需求的软件开发方法。领域驱动设计的前提是:

BeginnerMind 4022

hi3519dv500 os04a10输入调试

因该sensor接在soc端的iic6,在驱动中(Hi3519DV500_SDK_V2.0.1.1\smp\a55_linux\source\mpp\cbb\isp\user\sensor\hi3519dv500\omnivision_os04a10\os04a10_sensor_ctl.c)注意总线的选择。mem_process_isolation=1 改为 mem_process_isolation=0。2、OT_MIPI_SET_HS_MODE配置为LANE_DIVIDE_MODE_1。

linus 3164

「分治法」最近点对距离问题

一、问题描述 给定平面S上n个点,找其中的一对点,使得在n个点组成的 所有点对中,该点对间的距离最小。 假设所讨论的点是以标准笛卡儿坐标形式(x, y)给出的。因 此,在两个点Pi =(xi , yi )和Pj =(xj , yj )之间的距离是标准的欧几里德 距离: d = 根号下( x i − x j ) 2 + ( y i − y j )2 二、问题分析 直接用暴力解法很简单,用结构体把每个点的x、y坐标都存下来之后,用一个二重循环即可获得距离的最大值。但是这样做的时间复杂度也达到了O(n的平方)

Laok0413的博客 9656

领域驱动设计(Domain Driven Design)参考架构详解

领域驱动设计(Domain Driven Design)参考架构详解摘要本文将介绍领域驱动设计(Domain Driven Design)的官方参考架构,该架构分成了Interfaces、Applications和Domain三层以及包含各类基础设施的Infrastructure。本文会对架构中一些重要组件和问题进行讨论,给出一些分析结论。本文原文连接:http://blog.youkuaiyun.com/b

Laurence的技术博客 7万+

YOLOv8改进,MobileNetV3轻量化架构改进特征提取网络,助力涨点

MobileNetV3通过结合硬件感知网络架构搜索(NAS)和NetAdapt算法,通过新颖的架构改进进一步提升了性能。本文开始探讨了自动化搜索算法与网络设计如何协同工作,以利用互补方法来提升整体技术水平。通过这一过程,创建了两个新的MobileNet模型:MobileNetV3-Large和MobileNetV3-Small,分别针对高资源和低资源使用场景。这些模型随后被适配并应用于目标检测和语义分割任务。

在职AI算法工程师,擅长计算机视觉,YOLO目标检测、分割等,擅长web、pyqt界面可视化,好内容持续更新中,来这里跟大家一起学习,共同进步 3835

领域模型驱动设计(Domain Driven Design)入门概述 -----DDD 解释

软件开发要干什么: 反映真实世界要自动化的业务流程 解决现实问题 领域Domain Domain特指软件关注的领域 在不能充分了解业务领域的情况下是不可能做出一个好的软件 领域建模 领域模型驱动设计 } 分层架构 } 实体 } 值对象 } 服务 } 模块 } 聚合 } 工厂 } 资源...

148

k3s cpu load 和 cpu 使用率很高处理

在这期间还执行过缩减 sqlite3 数据库操作,不知道是哪个操作起了作用,亦或者两个操作有影响,删除 ns 促进了数据库缩减的执行(没删除之前数据库缩减不成功,db文件大小未减小,但不确定是不是执行完 VACUUM 之后需要时间 db 文件才会减小,或者是因为删除了 ns 才导致其减小),再或者是两个操作都起了作用。kubectl get ns 发现有很多卡在删除状态的 ns。k3s 官网关于这个问题的谈论。执行如下脚本删除掉这些 ns。有人详细说过这个问题。

weixin_40548182的博客 682

FPGA SoC 的 RISC-V 固件开发全攻略(三):RISC-V MCU 启动流程深入解析

本文是《FPGA SoC 的 RISC-V 固件开发全攻略》专栏第 3 篇。上一篇:第 2 篇《开发环境搭建与工具链避坑》 | 下一篇:第 4 篇《RISC-V 与 ARM Cortex-M 开发差异对比》

XavierKong的博客 43
上一篇: webservice CXF入门图解 附实例源码
下一篇: linux 发布java项目操作手记
评论 3
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值