![](https://img-blog.csdnimg.cn/20210715082553150.jpg?x-oss-process=image/resize,m_fixed,h_224,w_224)
架构、代码优化与领域驱动开发
文章平均质量分 86
领域驱动开发的一系列流程
晓风残月淡
这个作者很懒,什么都没留下…
展开
-
实现领域驱动设计(DDD)系列详解:领域模型的持久化
领域驱动设计主要通过限界上下文应对复杂度,它是绑定业务架构、应用架构和数据架构的关键架构单元。设计由领域而非数据驱动,且为了保证定义了领域模型的应用架构和定义了数据模型的数据架构的变化方向相同,就应该在领域建模阶段率先定义领域模型,再根据领域模型定义数据模型。这就是领域驱动设计与数据驱动设计的根本区别。如果领域建模采用对象建模范式,存储数据则使用关系数据库,那么领域模型就是面向对象的,数据模型则是面向关系表的。原创 2024-07-25 22:33:10 · 638 阅读 · 0 评论 -
实现领域驱动设计(DDD)系列详解:异常处理
使用好异常的关键在于让它表达一定的领域含义,即细分模型不愿处理的条件,抛出有领域含义的异常,以便让合适的上级调用者找到合适的处理方式。显然,“购物车已满”的异常比“数组越界”的异常更容易让调用者知道如何处理。有些专家建议,当语言框架中已有相应异常时,不要自己创建异常,这适用于语言级别的异常。对于领域层来说,自定义异常是领域逻辑的一部分,它可以丰富通用语言。相比于错误代码,自定义异常能够很自然地被领域专家所理解。原创 2024-06-10 13:17:21 · 961 阅读 · 0 评论 -
实现领域驱动设计(DDD)系列详解:聚合生命周期的管理——对象工厂与资源库
和。许多面向对象语言都支持类通过构造函数创建它自己。对象自己创建自己,就好像自己扯着自己的头发离开地球表面,完全不合情理,只是开发人员已经习以为常了。然而,构造函数差劲的表达能力与脆弱的封装能力,在面对复杂的构造逻辑时,显得有些力不从心。遵循“最小知识法则”,我们不能让调用者了解太多创建的逻辑,以免加重其负担,并带来创建代码的四处泛滥,何况创建逻辑在未来很有可能发生变化。基于以上因素考虑,有必要对创建逻辑进行封装。领域驱动设计引入工厂(factory)承担这一职责。原创 2024-04-29 09:19:14 · 984 阅读 · 1 评论 -
编程错误的处理方式:防御式编程
防御式编程有这样一种思维,类似于驾驶汽车,永远不能确定其他司机会做什么,同时要保护好自己,哪怕是其他司机犯的错误。也就是说,子程序不因传入错误数据而被破坏,哪怕是其他子程序产生的错误数据。因此,如何处理错误数据?有三种方式:检查来源于外部数据的值检查子程序所有输入参数的值决定如何处理错误的输入数据一、断言断言是用在开发和维护阶段的,生产环境又被去除,以免降低系统的性能。错误处理代码处理预期会发生的情况检查有害的输入数据对错误进行正确反映断言处理绝对不应该发生的情况。检原创 2021-05-12 11:07:31 · 376 阅读 · 0 评论 -
领域驱动设计实现疑难解答(六):如何集成多个限界上下文?
一般主题域是复杂的,需要分离成多个限界上下文。1.概述比如开放论坛应用中,需要识别用户身份,需要实现论坛发言等等。若将身份识别和授权的逻辑,与论坛发布文章和评论的逻辑相混合,会让开发陷入混乱。这时需要分离出身份与访问上下文,论坛上下文等限界上下文。我们来分析:分离限界上下文后,身份与访问上下文需要通过REST的方式对外发布服务。论坛上下文需要远程访问来自上游的身份与访问上下文的数据,并且不会存储该数据,需要每次都去访问身份与访问上下文。显然,论坛上下文依赖于远程服务,不具有自治性。访问方式:下原创 2021-07-15 08:24:10 · 215 阅读 · 0 评论 -
概念POJO、DTO、DAO、PO、BO、VO、QO、ENTITY详解
在java开发过程中,新手总是被DAO、PO、BO、VO等等概念弄得晕头转向。下面我查找了很多资料,总结如下:POJO(Plain Ordinary Java Object 简单Java对象)实际就是普通JavaBeans,是为了避免和EJB混淆所创造的简称。POJO的内在含义是指:那些没有继承任何类、也没有实现任何接口,更没有被其它框架侵入的java对象。它包括PO、DTO、VO、BO等。POJO持久化-》POPOJO传递-》 DTOPOJO在表示层-》VOPO(persistence o原创 2020-10-11 11:27:18 · 26103 阅读 · 9 评论 -
实现领域驱动设计(DDD)系列详解:如何渲染数据给用户界面
如何渲染数据?用户界面有很多种比如命令行,桌面应用,web应用。那么如何将领域对象渲染到用户界面,或者如何将操作反映到领域模型上?用户界面常需要渲染多个聚合实例中的属性,但是只能修改其中一个聚合。1渲染数据的方法1.1通过DTO渲染多个聚合实例DTO将包含所有需要显示的属性,应用服务通过资源库读取多个聚合,再通过DTO组装器将多个属性映射到DTO中。用户界面将访问DTO中每一个属性,并渲染到显示界面。这样做好处是不会存在延迟加载问题,并且解决展现层和业务层物理分离的情况。坏处是需要创建很多与原创 2021-05-21 11:27:31 · 389 阅读 · 0 评论 -
领域驱动设计实现疑难解答(三):如何处理关联
有了模型之后,领域最重要的是处理业务逻辑。如何处理关联?对象都有声明周期,它们在生命周期内与其他对象具有复杂的相互依赖性,它们会经历一些状态变化,并遵守固定的规则。因此,管理这些对象面临挑战!有3种模式解决这些问题:1.使用AGGREGATE(聚合)定义清晰的所属关系和边界,以维护生命周期的完整性2.使用FACTORY(工厂)创建或重建复杂对象和聚合,从而封装它们的内部结构3.使用REPOSITORY(资源库)提供查找和持久化对象并封装庞大基础设施的手段总结起来,就是使用聚合进行建模和划分范围原创 2021-05-21 11:23:48 · 934 阅读 · 0 评论 -
实现领域驱动设计(DDD)系列详解:如何设计实体和值对象,进行领域建模
划分好限界上下文后,需要面临的是如何建模?1.实体由标识定义的对象称之为实体,由属性决定的对象称之为值对象。比如体育馆的一排座椅,当进入体育馆有座次区别时,座椅是实体。当进入体育馆靠入场券时,不区分座次,座椅是值对象。所以实体和值对象的区分依赖于具体环境。每个实体必须有唯一的实体标识,区分其他实体,即使这些实体属性相同,或在分布式系统中。面向对象原有的语言,就会给对象创建唯一对象标识。然而,在持久化之后,重新创建对象实例,这些对象标识就丢失了。因此如何判定两个对象属于同一实体,需要理解领域才能定原创 2021-05-21 11:18:46 · 441 阅读 · 1 评论 -
领域驱动设计实现疑难解答(一):如何分包及组织工程结构
接到一项业务,我们首先下意识要解决这些问题,而为了解决业务问题,需要处理用户输入,处理业务逻辑,访问数据库,进行网络通信,向用户显示信息等。而其中处理业务逻辑,是我们最需要关注的事情。由于我们是领域驱动设计,而不是数据表驱动设计,所以我们优先考虑某场景下实体可能有哪些业务行为,而不是实体有哪些属性,也即根据用例流来设计软件。如何分包以及组织工程结构?在DDD的战略设计中,我们关注于从一个宏观的视角俯视整个软件系统,然后通过一定的原则对系统进行子域和限界上下文的划分,即通过软件所实现的业务功能进行模块原创 2021-05-21 11:16:25 · 727 阅读 · 0 评论 -
领域驱动设计术语:命令对象
考虑一个应用服务接口,如下:public interface UserService { public void activeUser(UserId userId); public void deactiveUser(UserId userId); public User addUser(String name, String password, String mobile, String email, Adress adress); public User user(UserId userId)原创 2021-05-07 16:53:45 · 379 阅读 · 0 评论 -
实现领域驱动设计(DDD)系列详解:如何发布领域事件
领域事件把领域中发生的活动建模成一系列离散事件,领域事件是领域模型的组成部分,表示领域中发生的事情。一般,一个业务用例对应一个事务,一个事务对应一个聚合根,也即在一次事务中,只能对一个聚合根进行操作。但是在实际应用中,我们经常发现一个用例需要修改多个聚合根的情况,通过引入领域事件,我们可以很好地解决上述问题。这时候称为基于事件的最终一致性。(1)创建领域事件找出事件可以通过事件风暴活动找出领域事件,领域事件是用来捕获领域中发生的具有业务价值的一些事情,是领域专家所关心的(需要跟踪的、希望被通知的原创 2021-04-04 23:06:42 · 1587 阅读 · 2 评论 -
实现领域驱动设计(DDD)系列详解:如何设计聚合
前面第二次迭代完成,就该实际完成业务逻辑了。1.聚合根的设计聚合根是主要的业务逻辑载体,DDD中所有的战术实现都围绕着聚合根展开。一个大而全的聚合根可以囊括所有业务逻辑,这前景很诱人,但是却不合适,易造成并发风险。例如,一篇博客包括标题、内容、作者、标签、评论等。public class Blog{ private BlogId blogId; private String title; private Author author; private Post pos原创 2021-03-20 17:33:11 · 1461 阅读 · 1 评论 -
领域驱动设计实现业务流程:开始开发
在之前的第一次迭代完成后,可以测试是否能正常响应。接下来该完成实际业务逻辑。1.应用服务应用服务,是领域模型的门面。在DDD中业务被提到第一优先级,所以我们希望对业务的处理能提取出来。在DDD中,实现业务功能应该采用自顶向下的实现方式。ApplicationService采用了门面模式,作为领域模型向外提供业务功能的总出入口,就像酒店的前台处理客户的不同需求一样。//示例代码OrderApplicationService://该方法目的为改变订单中产品的数量,必须是事务操作@Transacti原创 2021-03-17 23:51:00 · 429 阅读 · 0 评论 -
领域驱动开发和面向数据开发的思考
通常在面对一项业务需求时,技术人员首先想到的是会有哪些信息?要存储哪些字段?如何设计一个数据库表。然后再针对数据库表进行增删查改,完善业务逻辑,操作这些信息,最后完成需求。我总结为,这是一个先形成“物”的概念,然后再完成“事”的概念,是自下而上的开发(从数据库开始编码到控制界面编码)。这看起来很自由,毕竟有了数据,随便事情怎么变动,都可以完成逻辑。然而,这是基于数据库表不再变动的情况下的,如果之前考虑不周,在数据库表上要删除或增加几个字段,那改起来就麻烦了。在领域驱动设计中,思考方式就有所不同,我们原创 2020-11-30 21:22:39 · 734 阅读 · 0 评论