程序男的专栏

最近公司准备进行业务组件的开发，正好我也准备讲一下《DDD理论与实践》的技术分享，在进行通用业务组件设计方案的时候发现了一个特别容易理解也很容易讲明白的案例，这里专门记录一下，分享给大家。...

今年在DDDChina上认识了很多行业大佬，也跟着学习了一波，在领域建模的过程中关于实体，值对象和聚合的讨论比较多，也看了一些大佬的书。在大佬眼力进行领域模型设计的时候把聚合当作基本单元看着是比较随意的事情，但是对于初学者来说可能还需要一些时间消化。这里来简单探讨下整个问题。......

之前有群友讨论领域相关的业务能力，平台能力，领域能力，商业能力是什么？这个问题比较有意思，当即记下来后续专门讨论下，本文将从一些简单的方面来阐述这几个能力之间的区别。

前面两篇已经大体讨论了整个软件系统中的复杂度相关的衡量指标，但是如何相对客观的通过复杂度模型来构建出来并输出相关复杂度数据，就需要对不同的衡量指标和影响因素做量化，同时需要仔细考量不同复杂度因素之间的相关性和其在真实业务场景下的权重。本篇文章将通过一些分析思维和建模方法来构建一个软件复杂度评估模型。...

上一篇重点讲述了软件复杂度的由来和现象，以及不同视角下的复杂度是怎么呈现的，本篇文章将从更细致的方面来阐述形成复杂度的一些指标数据，并按不同维度进行区分。这么做的一个原因就是希望通过本篇文章让软件复杂度更具象，让软件开发者更直白全面的感受复杂度。...

自从Eric的书名中提到如何应对软件复杂度的问题，后面的很多其他大佬都在尝试用自己的方式来阐述软件复杂度和如何应对软件复杂度。但是我们可能忽略了一个基本的问题就是我们如何衡量它。在软件架构工程中有一些复杂度函数，比如neal的适应度函数等。比如一些衡量耦合相关的指标和数学函数信息，但是这只是整个软件工程中的某个方面的复杂度的信息，对大多数软件从业者来说，这显得有点专业了。...

基于上下文的业务流建模法的文章系列已经到了第四篇了，本篇也是最后一篇，来讲一下关于这个建模方法的一些缺点以及如何优化它，基于这个建模方法我们如何更好更快的构建业务模型。

前面两篇文章已经给大家展示了一个相对新颖的建模方法，也简单实战了下，这里我通过一个生活中的例子来模拟快递业务中的模型构建过程，本篇将完整的展示一下基于上下文的业务流建模法的操作过程。...

上一篇文章说到了我提出了一种新的建模方法，并对建模方法的大概内容做了阐述，本次我将继续对这个建模方法做进一步的说明,并提供一个小小的案例来熟悉一下建模套路。下一篇文章将通过其他案例来展示这种建模方法的优势。...

DDD相关的建模方法就目前看已经在实践的建模方法已有6种之多，之前的技术分享中也有大佬尝试通过一些新的方法或者理论来帮助统一DDD建模，这其中的原因也是因为希望找到一个比较好的或者适用性更广的建模方法。当然我也在思考这个问题，并且尝试用一些新的方式来优化当前已经使用的建模方法中存在的缺点。因此在本系列中我将尝试通过3篇左右的文章来提出一个新的建模方法，有可能读完之后感觉就是之前所有的建模方法的结合体，但是这并不妨碍你更好的运用建模方法来构建软件模型。...

前面几篇已经从各个方面说统一语言不能统一的一些原因，但是我们终究希望让统一语言可以在团队中达成一些共识，并让统一语言在沟通，代码和应用上面提供一些帮助。本文将是统一语言的最后一篇文章，将重点探讨统一语言有可能统一的一些方法。文末也有整理关于本系列的完整思维导图，需要的话可以收藏。

上一篇我们讲到了统一语言与各个方面因素的关系，从这些关系中可以看出如果要让统一语言统一，同时带来一定的收益，我们就要深入去了解统一语言可管理可控制的一些方法或者工具，本篇将从工具的角度来阐述一下统一语言在用工具管理过程中出现的一些问题，以及为什么这些工具没有发挥最好的效果。

在上一篇文章中，重点讲述了统一语言在文化等方面存在的一些差异，这些差异本身也体现了世界的差异，包括国与国之间,人与人之间等的互动是客观存在不一致的，那么统一语言本身而言就无法达到高度统一，但是有可能是可以达到共识的，本篇将从统一语言与其他方面的关系来简单阐述一下统一语言为什么不能统一的问题。

学了DDD也大半年了，看事物也总喜欢从更多的维度去看，因此对于需求而言，总可以归为从问题空间到解空间的映射。不过有时候这种从领域的角度或者领域驱动设计的方式去跟人沟通的时候发现是挺痛苦的，毕竟需要去理解不同的人在不同的上下游说的不同的词是什么意思，是不是指的同一个事物，同一个系统，同一个场景。所以，当从领域驱动设计的统一语言模式去应用的时候，其实还是非常难的。因此，本系列将探究一个关于DDD统一语言模式的问题，以及可能的解决方法。

最近通过COLA构建篮球运营管理平台演示源码的时候对跨层调用做了一些深度思考，在跨层调用中有些调用并不是严格按规范或者相对固定的分层模式去走的，这就出现了一些疑问，比如不按规范来我怎么控制代码质量，我怎么知道最佳实践是什么？

在DDD讨论群中与一位群友讨论了一个关于领域服务拆分的问题，这个也涉及到了代码层面的操作和设计，比如一个领域服务中包含多个子领域，随着业务的发展或者迭代，某个子领域需要拆出来独立迭代。很多程序员多少都会遇到这种情况，尤其是分布式微服务下的架构模式，因此本文就这个话题着重讨论一下DDD中的领域上下文的拆分和合并。

这个话题是突然间从脑海中闪过的，感觉有点意思，可以聊一下，类似于学习的三种境界。很多技术文章或者技术人都会有这三种境界，现在带大家感受一下。

最近看了一些大佬的公众号以及一些培训DDD的宣传课程，发现有很多都在宣传基于事件驱动的领域建模方法，这里就简单分析一下为什么大佬们都喜欢用这个方法来构建领域模型。

一、背景在前一段时间里有一篇文章比较火，说service必须要有个实现接口吗？这个在各大公众号上进行转载，引起Java技术网友的广泛评论，我也简单说了下个人的观点。最近正好也在不同的场景用到了独立类，没有实现接口。本文将结合DDD的独立类模式来重点探讨如何用好独立类，如果才不一刀切的看待独立类的使用。二、独立类简述2.1 独立类的简单概括简单来说就是没有实现接口，没有实现抽象类的Java类，当然枚举和注解这里不是我们讨论的话题。2.2 哪些算是独立类通常来说很少有机会对模型进行实现接口比如DTO

之前群里有人分享基于贫血模型和充血模型相关的一些代码实战，同时也有一些小伙伴不太理解这些模型之间的真正内容，本文将通过一个扣库存的代码工程实践来阐述不同视角下的扣库存逻辑的实现。

最近有微信朋友在公司内部分享的时候有人问领域划分的规则是什么？意思就是你怎么知道一个领域需要划分哪些子领域？有没有依据，是凭直觉吗？本文将重点讨论下这个比较现实的问题。同时根据网友的试读建议本文进行了思维导图的总结，可以保存收藏。

这个组件是接着这篇文章《用一个极致简单的场景演练领域建模》进行设计的，根据不同业务场景实现不同的业务场景Service能力。从组件的应用架构图上看，麻雀虽小，五脏俱全。这个组件可以方便的进行集成和二次开发，基本可以作为组件小而美的典型。

.png&originHeight=341&originWidth=835&originalType=binary&ratio=1&s

一、传统架构下的Service1.1 SSH时代到目前为止还好，曾经用过SSH框架，那时候不懂分层，前后端还不分离。当然，走出校园之后SSH就没有碰过了。在SSH中使用struts action做控制层路由，hibernate做持久化。spring 做bean容器，最后的业务就是在一个项目工程中由struts action类到service bean然后到hibernate dao就可以了。1.2 MVC时代在MVC框架思想中MVC基本上代表了前后端之间的桥梁，服务层依然在幕后操作。但是mybati

一、背景目前低代码生成领域非常火爆，而且市场价值在逐步上升，很多巨头都在重金投入。低代码的出现意味着程序员可以从大量重复低效的劳动中脱离出来，同时可以更好更快的支持业务解决实际问题，极大的提高了交付价值的效率。那么在DDD中实际上也有一些人尝试使用低代码的方式进行建模，意图将建模过程程序化，自动化，通过模板或者预设脚本得到建模结果。本章内容则重点讨论DDD下的代码文档生成的意义，以及这种思路将带给我们什么启示。二、观点2.1 观点1–手动构建很多研究DDD的人都会遇到这个问题–是否使用低代码来降低建

一、背景在之前的文章中已经介绍了DDD相关的概念模式，DDD相关的业务技术架构，但是我们还没有找到一个核心的抓手去实践DDD。DDD的一个核心本质就是对业务建模，或者领域建模。说的很简单，但是做好确实很难，一个需求过来意淫几个实体对象就差不多解决了。深入看，全局看只在脑海中进行的建模实际上并不一定正确和稳定。因此我们需要找到正确的方法帮助对业务领域进行分析，得到建模结构，共享建模成果。二、四色建模法2.1 起源&概念&要素关于四色建模的概念我们可与追溯到90年代，起源于四色原型。四色

一、通用语言模式回顾1.1 通用语言模式（UBIQUITOUS LANGUAGE）通用语言有时也叫统一语言，但是这里我们叫它通用语言。摘录：UBIQUITOUS LANGUAGE（通用语言）的词汇包括类和主要操作的名称。语言中的术语，有些用来讨论模型中已经明确的规则，还有一些则来自施加于模型上的高级组织原则。​1.2 注意事项将模型作为语言的支柱。确保团队在内部的所有交流中以及代码中坚持使用这种语言。在画图、写东西，特别是讲话时也要使用这种语言。通过尝试不同的表示方法（它们反映了备选模型）来消除

一、背景在学DDD的时候我首先看的是《领域驱动设计-软件核心复杂性应对之道》，这本书里记录了很多概念，方法，思想，策略，模式等。整体读下来非常费劲但是收获也不小，如何转化为自己的能力就需要深入揣摩了。很多人觉得DDD门槛很高，或者DDD相关的概念，落地都比较杂，看得令人眼花缭乱，从网上找资料也很不全，不成体系，大部分都是别人一知半解的二次咀嚼思考的产物。因此DDD在很多工程师的眼里就像雾里看花一样，这里我通过这本书简单总结DDD里常见的概念，方法，思想，策略，以及本书没有提到的一些模式。二、模式介绍2

总纲图1![统一语言与模型驱动.png](https://img-blog.csdnimg.cn/img_convert/f8ebcb064e29899ec1ddbec4760bc869.png#height=970&id=STaKC&margin=[object Object]&name=统一语言与模型驱动.png&originHeight=970&originWidth=788&originalType=binary&ratio=1&si

一、关于现实建模现在的软件工程发展的越来越快，我们理解现实中的业务形态，技术形态也越来约成熟，但是从现实走向计算机软件系统里却没有巨大的飞跃。作为开发工程师接到一个需求，或者作为科学家解析科学数据都需要用专门的工具进行软件需求设计，编码和实现。我们理解产品经理或者项目经理的一个职能就是将现实世界的问题通过产品文档，UI图，流程图等描述出来。然后开发工程师或者专家进行进一步的需求拆解处理，形成一定的数据结构。这里初步构建了一个对现实问题或者场景的解释。当然也慢慢让计算机更容易接受这个映射的过程。现在的计算机