ddd

首先澄清一点， 我这篇文章中菜鸟来菜鸟去叫嚣， 仅仅是为了配合文章主题， 不代表我本人对比我更聪明、 更有能力的人的否定； 只是某些牛人借以成功或者出位的东西， 其价值放到更久远的过去与未来， 其作用放到形形色色的具体环境中去， 究竟几何， 我个人认为必须持谨慎甚至怀疑的态度； 更不论跟我们的生存相关的那些问题了。 既然有那样的人和那样的组织， 可以通过产品、 书籍、 某某大奖、甚至自己的从业经历以及地位等各种各样的方式，行使他们的宣传能力所具有的舆论暴力， 让众多希望凭借掌握某些东西从而获得更好的生活、 更多的心理满足的人们随声附和， 那么我想， 我也应该有在夹缝中惊声尖叫的勇气。 从DDD看方法论的产生与流行 以前大概了解过一下DDD， 也下载了电子书（因为不确定值得一买）， 吸收了其中一些想法， 放弃了另外一些。刚才看一兄弟的博客， 看又提到DDD， 顺着他提供的链接， 下载了InfoQ的DDD简版， 打算重温一下。 怎么说呢， 也许是关注点变化了， 我个人认为DDD在交流到分析这一块还是相当棒的， 但是从分析到设计再到实现， 尤其是一些结论， 很多是菜鸟对自身能力不足的屈服。 也许某个不小心点入 我博客 的人， 正在跟随这些“菜鸟”， 那么您的感受我是可想而知的， 事实上， 我自己也是个菜鸟， 而且我本来决定不再提这些招人厌烦的话了。 我自己是个年轻人， 不是老古董，

DDD做为软件设计方法于2004年提出，一直不温不火，最近几年突然火起来了，为啥呢？正所谓机会给有准备的人，因为微服务的流行，大家都跃跃欲试把传统单体软件转成微服务架构，但理论很丰满，现实很骨感，光是分解微服务就让人找不到北，而DDD是歪打正着也好，富有远见也好，正好适合微服务转型设计，不火都难。 最近学习了领域驱动设计（Domain-Driven Design），感觉受益匪浅，那到底啥是DDD呢？这里分享一下学习心得。网上有很多详细的资料，感兴趣可以看看这个 https://www.infoq.cn/article/implementation-road-of-domain-driven-design 。 个人理解： DDD首先是一种 设计思想 ，所谓思想就是回答“设计的本质是什么，主要逻辑是什么”这类大的问题。DDD强调要从业务视角思考怎么设计软件架构，设计一定要知道业务是什么样子的，业务的需求和问题是啥，有啥内在逻辑，而不是从软件技术技术本身出发，这个对设计而言就是大的方向问题。虽然这个方向说出来好像没什么，但是实践上很多软件人员更多是从软件本身开始设计，一遇到业务问题就绕道走，所以强调从业务出发是这个方法最有价值的地方，这种梳理就称为战略设计。 DDD不只回答了方向问题，也提供一套 方法 ，软件设计是个高度逻辑化的工作，需要概念特别清晰，推导过程有章法可循

文章目录 DDD分层与传统三层区别 DDD分层详解 四层架构图 分层作用 领域对象 DDD编码实践 代码结构描述 领域模型注入仓储类的问题 DDD分层与传统三层区别 根据DDD领域驱动设计原则，对应的软件架构也需要做出相应的调整。 我们常用的三层架构模型划分为表现层，业务逻辑层，数据访问层等，在 DDD 分层结构中既有联系又有区别， 个人认为主要有如下异同： 在架构设计上，在 DDD 分层结构中将传统三层架构的业务逻辑层拆解为应用层和领域层 其中Application划分为很薄的一层服务，非核心的逻辑放到此层去实现，核心的业务逻辑表现下沉到领域层去实现，凝练为更为精确的业务规则集合，通过领域对象去阐述说明。 在建模方式上， DDD 分层的建模思维方式有别于传统三层 传统三层通常是以数据库为起点进行数据库分析设计，而 DDD 则需要以业务领域模型为核心建模（即面向对象建模方式），更能体现对现实世界的抽象。 故 在DDD分层凸显领域层的重要作用，领域层为系统的核心，包括所有的业务领域模型的抽象表达 。 在职责划分上，基础设施层涵盖了2方面内容 持久化功能，其中原三层架构的数据访问层下沉到基础设施层的持久化机制实现 通用技术支持，一些公共通用技术支持也放到基础设施层去实现。 DDD分层详解 四层架构图 在该架构中，上层模块可以调用下层模块，反之不行。即 Interface ——>

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 在实际的项目中，我们可能随时面对各种不同的需求，它的各个方面的要素决定了我们所采用的开发模式。 比如，它的复杂度如何？所有的需求是否足够清晰？开发人员对相关的业务是否足够了解？项目的工期是否合理？种种问题，不一而足。这也决定了我们可能面对不同的需求可能需要采用不同的开发模式。下面大概说几种。 1. TDD TDD指的是Test Drive Development，很明显的意思是测试驱动开发，也就是说我们可以从测试的角度来检验整个项目。大概的流程是先针对每个功能点抽象出接口代码，然后 编写单元测试代码，接下来实现接口，运行单元测试代码，循环此过程，直到整个单元测试都通过。这一点和敏捷开发有类似之处。 TDD的好处自然不用多说，它能让你减少程序逻辑方面的错误，尽可能的减少项目中的bug，开始接触编程的时候我们大都有过这样的体验，可能你觉得 完成得很完美，自我感觉良好，但是实际测试或者应用的时候才发现里面可能存在一堆bug，或者存在设计问题，或者更严重的逻辑问题，而TDD正好可以帮助 我们尽量减少类似事件的发生。而且现在大行其道的一些模式对TDD的支持都非常不错，比如MVC和MVP等。 但是并不是所有的项目都适合TDD这种模式的，我觉得必须具备以下几个条件。 首先，项目的需求必须足够清晰

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 在实际的项目中，我们可能随时面对各种不同的需求，它的各个方面的要素决定了我们所采用的开发模式。 比如，它的复杂度如何？所有的需求是否足够清晰？开发人员对相关的业务是否足够了解？项目的工期是否合理？种种问题，不一而足。这也决定了我们可能面对不同的需求可能需要采用不同的开发模式。下面大概说几种。 1. TDD TDD指的是Test Drive Development，很明显的意思是测试驱动开发，也就是说我们可以从测试的角度来检验整个项目。大概的流程是先针对每个功能点抽象出接口代码，然后编写单元测试代码，接下来实现接口，运行单元测试代码，循环此过程，直到整个单元测试都通过。这一点和敏捷开发有类似之处。 TDD的好处自然不用多说，它能让你减少程序逻辑方面的错误，尽可能的减少项目中的bug，开始接触编程的时候我们大都有过这样的体验，可能你觉得完成得很完美，自我感觉良好，但是实际测试或者应用的时候才发现里面可能存在一堆bug，或者存在设计问题，或者更严重的逻辑问题，而TDD正好可以帮助我们尽量减少类似事件的发生。而且现在大行其道的一些模式对TDD的支持都非常不错，比如MVC和MVP等。 但是并不是所有的项目都适合TDD这种模式的，我觉得必须具备以下几个条件。 首先，项目的需求必须足够清晰，而且程序员对整个需求有足够的了解

目录 概述 开篇 字段 Or 表 来说一下持久化为字段的情况 来说一下持久化为表的情况 怎么持久化集合值对象 将集合值对象存为字段 将集合值对象存为表 基于快照的数据存储对象 比较 总结 概述 在实践领域驱动设计（DDD）的过程中，我们会根据项目的所在领域以及需求情况捕获出一定数量的领域对象。设计得足够好的领域对象便于我们更加透彻的理解业务，方便系统后期的扩展和维护，不至于随着需求的扩展和代码量的累积，系统逐渐演变为大泥球（Big Ball of Mud）。 虽然领域驱动设计的思想很诱人，但我们依然会面临各种隐藏的困难，就比如今天我们要讲的主题“持久化”：即使前期我们设计了足够完整的领域对象，但是依然需要持久化它们到数据库中，而普通的关系型数据库可能很难维持领域对象的原有结构，所以我们必须要使用一些特有的手段来处理它。 开篇 本篇文章属于《如何运用领域驱动设计》系列的一个补充，如果您阅读过该系列的其它文章，您就会发现关于“持久化”的这个问题已经不止在一篇博文中提及到了。 那么，到底是什么原因让我们面临这个问题呢？ 是的！ 值对象！ 如果您认真的了解过值对象的话（ 如果还不了解值对象，您可以参考 如何运用领域驱动设计 - 值对象 ），您会发现值对象是由许多基元类型构成的（比如string,int,double等），所以我们可以理解它为对细粒度基元类型的包裹

DDD分层架构 Evans在它的《领域驱动设计：软件核心复杂性应对之道》书中推荐采用分层架构去实现领域驱动设计： image 其实这种分层架构我们早已驾轻就熟，MVC模式就是我们所熟知的一种分层架构，我们尽可能去设计每一层，使其保持高度内聚性，让它们只对下层进行依赖，体现了高内聚低耦合的思想。 分层架构的落地就简单明了了，用户界面层我们可以理解成web层的Controller，应用层和业务无关，它负责协调领域层进行工作，领域层是领域驱动设计的业务核心，包含领域模型和领域服务，领域层的重点放在如何表达领域模型上，无需考虑显示和存储问题，基础实施层是最底层，提供基础的接口和实现，领域层和应用服务层通过基础实施层提供的接口实现类如持久化、发送消息等功能。阿里巴巴开源的整洁面向对向分层架构COLA就采取了这样的分层架构来实现领域驱动。 改进DDD分层架构和DIP依赖倒置原则 DDD分层架构是一种可落地的架构，但是我们依然可以进行改进，Vernon在它的《实现领域驱动设计》一书中提到了采用依赖倒置原则改进的方案。 所谓的依赖倒置原则指的是：高层模块不应该依赖于低层模块，两者都应该依赖于抽象，抽象不应该依赖于细节，细节应该依赖于抽象。 image 从图中可以看到，基础实施层位于其他所有层的上方，接口定义在其它层，基础实施实现这些接口。依赖原则的定义在DDD设计中可以改述为

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 2019年参加了"领域驱动设计峰会2019"看到了国内、国外、不同行业在基于DDD的实践分享。 成年热学习的一个特点就是带着自己的经验来思考接收到的内容，那么回顾自己接触DDD有一段时间，将自己的经验和思考作用在项目上，真真切切替换了DDD带给我的提升。 本片内容将不会聚焦在哪些理论上，而是看看那些些提升我开发效率的技术部分（非具体代码的粒度）。 充血模型 代替 贫血模型 Domain + DomainService + ApplicationService 基础服务层 和业务保持一致 统一语言 01 用 充血模型 代替 贫血模型 充血模型的好处是让我最先感觉到收益的地方。 在之前的项目中很多都采用了三层的项目架构设计，短时间内看上去没有什么问题，但是随着项目的进行，Service层变得越来越臃肿，不得不加入其它的约束来让项目结构变得清晰。是的遇到问题、分析问题、解决问题。但是项目毕竟是个团队项目，所以有时候单个人遵守约束很容易，但是让团队都最受这种约束就变的困难的了，所以三层架构在原来的工作中确实带来了一部分问题。 是的，正如上面所言，在简单的场景下，采用贫血模型能够清楚的讲明白的。但是随着业务的丰富，想要通过代码接示业务意图变得异常的困难。 在接触DDD之后，项目开发中，领域模型使用了充血模型

何时定义领域服务 若遵循基于面向对象设计范式的领域驱动设计，并用以应对纷繁复杂的业务逻辑，则强调领域模型的充血设计模型已成为社区不争事实。我将Eric提及的战术设计要素如Entity、Value Object、Domain Service、Aggregate、Repository与Factory视为 设计模型 。这其中，只有Entity、Value Object和Domain Service才能表达领域逻辑。 为避免贫血模型，在封装领域逻辑时，考虑设计要素的顺序为： Value Object -> Entity -> Domain Service 切记，我们必须将Domain Service作为承担业务逻辑的最后的救命稻草。之所以把Domain Service放在最后，是因为我太清楚领域服务的强大“魔力”了。开发人员总会有一种惰性，很多时候不愿意仔细思考所谓“职责（封装领域逻辑的行为）”的正确履行者，而领域服务恰恰是最便捷的选择。 就我个人的理解， 只有满足如下三个特征的领域行为才应该放到领域服务中 ： 领域行为需要多个领域实体参与协作 领域行为与状态无关 领域行为需要与外部资源（尤其是DB）协作 假设某系统的合同管理功能允许客户输入自编码，该自编码需要遵循一定的编码格式。在创建新合同时，客户输入自编码，系统需要检测该自编码是否在已有合同中已经存在。针对该需求

学习DDD有一段时间了，总结了一幅图，包含了使用DDD进行战略设计、战术设计、以及最终代码落地的具体步骤，以及DDD的相关名词解释(领域，子域，通用语言，聚合，限界上下文，实体，值对象，聚合根等) 由于DDD的概念比较抽象，建议大家先看左侧的步骤，再看右侧的概念解释，也建议大家在学习DDD时，不要上来就死磕概念，可以先找些DDD落地指导方面的文章，搞明白大致流程后，再来深入概念，会轻松一点 接下来会介绍"DDD分层架构模型"，以及与其相似的"六边形架构"，然后基于DDD分层架构模型给出具体的代码设计方案图 来源： CSDN 作者： wb_snail 链接： https://blog.csdn.net/wb_snail/article/details/103721613