领域模型驱动设计(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 为 阅读详情

相关推荐

验证码接收平台搭建教程(含源代码)

在很多注册流程中,我们常常需要通过短信验证码验证用户的身份。本教程将手把手教你搭建一个验证码接收平台,用于自动接收并展示来自短信网关或短信转发器的验证码。⚠️ 本教程仅供学习使用,请勿用于任何非法用途!本教程展示了一个简单的验证码接收平台的搭建流程,从后端到前端完整实现。你可以将其用于学习 Web 开发、数据库操作以及 Flask 项目部署。访问我的优快云主页。

weixin_52548902的博客 4082

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

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

yunnuo的博客 1万+

【Matlab 六自由度机器人】基于改进型D-H参数的运动学建模与蒙特卡洛工作空间分析

本文详细介绍了如何使用改进型D-H参数法为六自由度机器人建立运动学模型,并利用Matlab Robotics Toolbox实现正运动学计算与可视化。通过蒙特卡洛法对机器人工作空间进行分析,生成三维点云图以直观展示其可达范围,为机器人选型与任务规划提供关键依据。

weixin_29040367的博客 438

Domain Driven Design(领域驱动设计)

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

BeginnerMind 4021

树莓派与ROS2

树莓派与ROS2(Robot Operating System 2)的结合使用为机器人开发、自动化控制以及物联网项目提供了强大的平台。

weixin_47695827的博客 1754

57、振荡扫描仪的挠性枢轴:原理、设计与材料选择

本文深入探讨了振荡扫描仪中挠性枢轴的工作原理、设计方法与材料选择。挠性枢轴因其无润滑、高精度、低周期性误差和潜在无限寿命等优势,广泛应用于光学、太空、医学和半导体等领域。文章分析了其在小角度下的优异性能与无法连续旋转等局限性,提供了关键设计公式,并对比了多种挠性材料的性能指标。同时,结合不同应用场景提出设计优化策略,并展望了微型化、智能化和高性能材料等未来发展趋势,为工程实践提供了系统的设计流程与选型建议。

numpy6sculptor的博客 95

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

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

Laurence的技术博客 7万+

杰理SDK入门教程(六):自定义按键事件

这篇教程介绍了在杰理AC695N芯片上实现自定义按键功能的完整流程,包含三个核心步骤:首先在key_event_deal.h文件中添加按键枚举定义;然后在adkey_table.c配置按键映射表,按模式和行为类型设置按键值;最后在app_common.c的消息处理函数中添加自定义按键逻辑。教程强调需注意不同模式按键表的列定义差异,并提供了具体代码示例,最后指导完成编译测试验证。全文结构清晰,配有关键代码截图,适合开发者快速上手自定义按键功能开发。

qq_42014563的博客 1016

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

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

148

基于STM32设计的环境检测系统(OneNet)_365

本项目设计并实现了一种基于STM32F103RCT6单片机的环境检测系统,系统集成了多种传感器模块,具备对环境温湿度、烟雾浓度、易燃气体浓度、一氧化碳浓度和整体空气质量的实时检测功能。系统通过1.44寸SPI接口LCD实现本地数据显示,同时配备有源蜂鸣器用于环境异常报警。在数据通信方面,系统利用ESP8266-WIFI模块,采用MQTT协议将各类传感器数据上传至OneNet云平台,并借助其可视化框架实现网页端可视化界面,可通过电脑和手机浏览器远程访问,实现环境数据的远程监控。该系统设计结构简单、功能全面,适

2189

SAP Clean Core 对传统 ABAP 开发人员来说意味着什么:机遇和挑战

SAP Clean Core是一种战略方法,旨在优化和现代化 SAP S/4HANA 系统,通过尽量减少定制,确保核心系统的稳定性、高效性和对云环境的兼容性。Clean Core 作为一种设计思路,致力于让 ERP 系统的核心功能保持简洁、规范,避免不必要的复杂化,最终维持一个标准化的核心,使系统更容易升级、性能更优越,同时支持快速的创新能力。

2007 年 ~ 2025 年,深耕 SAP 技术 18 年 610
上一篇: webservice CXF入门图解 附实例源码
下一篇: linux 发布java项目操作手记
评论 3
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值