![](https://img-blog.csdnimg.cn/95d328e19f3a4b04b71c846d35f2658d.png?x-oss-process=image/resize,m_fixed,h_224,w_224)
DDD
文章平均质量分 90
领域驱动设计那点事
爱琴孩
扫盲+科普+解惑,愿天下程序员每天少掉头发
展开
-
五年经验,应用分层还没搞懂?
总的来说业务分层对于代码规范是比较重要,决定着以后的代码是否可复用,是否职责清晰,边界清晰。当然这种分层其实见仁见智,团队中的所有人的分层习惯也不同,所以很难权衡出一个标准的准则,总的来说只要满足职责逻辑清晰,后续维护容易,就是好的分层。转载 2024-03-29 21:23:24 · 27 阅读 · 1 评论 -
事务脚本与领域模型那点事
在模型中,实体和值对象表示业务中的实际对象,聚合是由多个高内聚实体和值对象形成的组合提,领域服务表示不属于任何一个实体或值对象的操作,工厂则用于创建复杂的对象,比如实体和值对象等。领域驱动设计(Domain-Driven Design,DDD)是应对复杂业务场景的利器,它是对业务领域中的关键概念和业务规则的抽象。领域模型是一个对象模型,它主要描述各领域对象之间的关系和行为。和事务脚本不同,领域模型使用对象来承载业务逻辑,领域模型的设计基于业务领域知识,强调领域专家的参与,以提高软件系统的质量和开发效率。转载 2024-01-18 23:17:55 · 74 阅读 · 0 评论 -
贫血模型、充血模型的深入解读!
其实它们没有什么特别适用的方向,个人更倾向于总是使用充血模型,因为OOP总是比面向过程编程要有更丰富的语义、更合理的组织、更强的可维护性—当然也更难掌握。另外,实际工程场景中使用充血模型,还会碰到很多很多细节问题,其中最大的难关就是“如何设计充血模型”或者说“如何从复杂的业务中分离出恰到好处且包含语义的逻辑放到VO的行为中”。更糟糕的是,很多人认为这些贫血领域对象是真正的对象,从而彻底误解了面向对象设计的涵义。如今,面向对象的概念已经传播得很广泛了,而要反对这种贫血领域模型的做法,还需要更多论据。转载 2024-01-18 22:13:13 · 43 阅读 · 0 评论 -
领域驱动设计的几种典型架构介绍
每⼀种输⼊和输出都是⼀个端⼝,每个端⼝都有具体的实现逻辑,因此整个应⽤系统的架构就是⼀些列的端⼝+适配逻辑组成,架构图就是⼀个多边形形状。:比如我们最早的就是单体应用,多个业务之间可能都没有进行分层,之后我们业务多了,都各自混淆在一起,后来我们就通过MVC、SSM、分层等方式进行业务拆分,保证业务与业务之间解耦。目前领域驱动设计是目前比较流行的一种架构设计,只需要按照领域驱动设计的四重边界进行架构设计,就能够很好的对各个领域解耦,对后期的业务垂直扩展、功能的水平扩展提供了良好的基础。转载 2022-11-19 20:50:13 · 221 阅读 · 0 评论