大约4年前,2017年底的时候,那时刚开始工作实习,武哥让我了解了解DDD,写了这篇Blog:【架构设计 领域驱动开发 一】三层VSDDD,当时打算好好了解了解的,无奈水平不够,对这些概念也是一知半解的,所以了解也不深入,见解也不一定正确,工作4年多了,再次学习和比较下MVC和DDD吧。概念和代码组织区别什么是贫血MVC模型开发?什么是DDD充血模型开发?MVC贫血模型开发模式MVC 三层架构中的
转载 2023-11-20 14:41:33
89阅读
DDD(Domain-Driven Design,中文名领域模型设计)是一种软件开发方法论,它强调将业务领域中的知识融入到软件设计中。DDD 强调将软件开发过程分为两个主要阶段:领域分析和领域建模。领域分析是指深入了解业务领域中的问题和需求,领域建模是将分析出的领域知识转化为软件模型。在本文中,我不再过多说明DDD的来龙去脉,我将用多个例子来详细说明使用 DDD 和不使用 DDD 的区别、优势和劣
文章目录背景说明官网Github构造diff测试测试修改测试新增集合比较封装CRUD自定义比较器使用注解类级别@Entity@ValueObject@Value@DiffIgnore@ShallowReference@IgnoreDeclaredProperties@TypeName属性@Id@DiffIgnore@DiffInclude@ShallowReference@PropertyNam
转载 2023-10-19 19:32:36
163阅读
在领域模型的行为设计中我们提到 2013-04-22 15:37 “@banq”的内容我们把A对象自身固有行为看成是A的一种能力,而把需要依赖其他对象的方法称为交互行为。哪些属于A的自身方法?哪些属于交互方法?设计思路和方法是如何考虑的? …那么什么是对象的固有行为?我们认为是那些保证该对象逻辑一致性的行为,称为对象的基本职责,保证自己的存在。迪米特法则(Law of Demeter)则详细
接上篇《DDD 实战 (10):冲刺 1 战术之服务设计(下)及技术决策》后,我们接下来的重点,就是要展示真正的代码实现了。在本篇中,我将围绕 TDD(Test-driven development, 测试驱动开发)编程方法为核心,演示前面完成的相关 DDD 设计是如何落地的。在本篇中,我将首先介绍 TDD 三重奏(写测试-写功能-重构)和相关原则,然后用实际代码演示 TDD 的工作流程,最后我会
转载 2024-05-08 17:53:54
217阅读
前段时间组织了小红花的新一期分享快速搞定数字化项目——采用领域驱动设计(DDD)建设一个电商平台,听完池总的这个分享之后,我终于是把这两年重新热起来DDD(以下称为现代DDD)和我十几年前熟悉的DDD(以下称为古典DDD)对应起来了,在这里谈一谈。DDD当然不是什么新概念,该思想源于2003年 Eric Evans编写的“Domain-Driven Design领域驱动设计”简称DDD,Evans
贫血模型和充血模型贫血模型:指的是领域对象只包含了对象的特征,而没有对象的行为。即 POJO 中只有对象的属性和属性的 get/set 方法,所有的业务逻辑都放在业务层。优点:各层次之间松耦合,结构清晰,领域对象只是用作存放和传输的载体。缺点:只有属性没有行为的对象是没有生命的,这样的对象不是真正的对象,而且业务逻辑层将会十分庞大。使用方式:在对象的外围构建一个 Facade 层还封装对象的某些原
DDD(领域驱动设计)的代码分层结构是一种组织和划分代码的方式,旨在更好地实现领域模型、业务逻辑和技术实现之间的分离,并提供清晰的职责划分和可维护性。DDD代码分层结构1. 用户界面层(UI Layer):用户界面层负责与用户进行交互,并向用户展示信息和接收输入。它可以是Web界面、移动应用程序、桌面应用程序等。该层主要负责接收用户的请求,并将其转发到应用服务层进行处理。2. 应用服务层(Appl
# Java开发模型DDD(领域驱动设计) 领域驱动设计(Domain-Driven Design,简称DDD)是由Eric Evans在他的著作《领域驱动设计:现代软件项目的复杂性应对之道》中提出的一种设计理念。DDD强调从业务领域的角度来构建复杂的系统,它注重于在代码中表达业务需求,并通过模型来驾驭复杂性。 ## DDD的核心概念 1. **领域(Domain)**:一个应用程序所要处理
原创 10月前
48阅读
概述:最近一直在搞Java-DDD模式开发的方案落地;个人的理解,DDD模式中,只要关注三个模块即可:A. application:应用层,可以是http接口服务,也可以是grpc服务接口,甚至是rpc服务;B. domain:领域层,主要是领域业务的具体实现,跟上层的应用没有任何关系;C. infrastructure:基础服务层,包括项目中的持久化之类的代码;那么,如何将这三层进行较好的解耦,
转载 2023-08-08 08:37:28
131阅读
DDD现在是指导代码编写,甚至是架构设计的思想,要详细了解DDD必须先了解“聚合根、实体、值对象”的含义,这块网上已经有不少相关文章,为了避免踩坑,博主推荐一篇:聚合根、实体、值对象一、界限上下文最近看了欧创新老师使用DDD拆分微服务的思想,感受
原创 2022-12-21 11:42:50
158阅读
【51CTO译文】我们曾不只一次的听到2010年将是Java模块化的一年的言论;也知道目前为Java提供模块化的OSGi正在受到IBM和Eclipse基金会的大力支持。但作为实现Java模块化应用的基础框架,OSGi似乎并不完美;我们经常能听到关于OSGi过于复杂的抱怨。从个人的角度,我以开放的心态去了解OSGi。令人失望的是,我发现它的规则非常复杂而且是低阶的(low-level),对于大多数企
 适配层Adapter@Api(tags = "邮箱配置") @Slf4j @RestController @RequestMapping("mailConfig") public class SysMailConfigController { @Autowired private SysMailConfigAppService sysMailConfigAppServ
# 理解DDD领域模型Java中的实现 领域驱动设计(Domain-Driven Design,简称DDD)是一种设计软件体系结构的方法,重点在于业务领域和复杂领域逻辑的建模。对于初学者,理解如何在Java中实现DDD领域模型可能有些挑战。这篇文章将为你提供一个清晰的实现流程,同时提供详细的每一步代码示例。 ## 实现流程 以下是实现DDD领域模型的基本步骤: | 步骤
原创 2024-10-26 05:33:50
17阅读
 领域事件用来表示领域中发生的事件。举例来说的话,领域事件可以是业务流程的一个步骤,比如投保业务缴费完成后,触发投保单转保单的动作;也可能是定时批处理过程中发生的事件,比如批处理生成季缴保费通知单,触发发送缴费邮件通知操作;或者一个事件发生后触发的后续动作,比如密码连续输错三次,触发锁定账户的动作。领域事件相关案例事件起点:客户购买保险 - 业务人员完成保单录入 - 生成投保单 - 启动
DDD核心知识体系概述领域领域子域总结限界上下文通用语言限界上下文总结领域对象实体实体的业务形态实体的代码形态实体的运行形态实体的数据库形态值对象值对象的业务形态值对象的代码形态值对象的运行形态值对象的数据库形态值对象的优势和局限实体与值对象的关系聚合和聚合根聚合聚合根如何设计聚合聚合的设计原则 概述DDD的核心知识体系主要包括领域、子域、核心域、支撑域、通用域、限界上下文、实体、值对象、聚合、
本文是DDD框架实现讲解的第三篇,主要介绍了DDD的Domain层的实现。Domain层是具体的业务领域层,是发生业务变化最为频繁的地方,也是业务系统最核心的一层,也是DDD关注的焦点和难点。这一层包含了如下一些domain object:entity、value object、domain event、domain service、factory、reposi
什么是领域驱动设计(Domain Driven Design)?简称:DDD是一种架构思想。是一套应对复杂软件系统分析和设计的面向对象建模方法论。 是一种软件开发方法。为什么需要领域驱动设计开发工程师是通过软件来解决问题,编写代码只是其中的一部分工作,设计和交流同样重要。领域驱动设计的目的是让软件系统在实现时准确的基于对真实业务过程的建模并根据真实的业务过程的调整而调整。领域驱动设计的两个阶段1
todo0 开篇中台本质是业务模型,微服务是业务模型的系统落地,DDD 是一种设计思想,它可以同时指导中台业务建模和微服务设计,它们之间就是这样的一个铁三角关系。DDD 强调领域模型和微服务设计的一体性,先有领域模型然后才有微服务,而不是脱离领域模型来谈微服务设计。1 微服务 DDD2 领域、子域、核心域、通用域和支撑域DDD 的领域就是这个边界内要解 决的业务问题域。 我们把划分出来的多个子领域
tdd java 再次问好! 在上一篇博客文章中,我在没有紧密引用Java的情况下总体上解释了TDD理论 ,但是在这一部分中,我们开始进行TDD实践。 我们的目标是遍历TDD的所有阶段:从需求分析到测试代码的重构。 我们将在具有Java,JUnit和“ fake”需求的示例中完成所有这些工作。 需求分析 假设我们需要在一个虚构的应用程序中创建一个新功能。 以下用户故事描述了此功能: 作为用
转载 2023-07-14 17:21:13
60阅读
  • 1
  • 2
  • 3
  • 4
  • 5