领域驱动设计

今天，技术总监给我们上了一堂有关DDD 的课程，感触颇多，特此记录！ 1、问题 1.1、面向对象 虽然一直在说面向对象编程，但实际开发中一直没有做深入思考，更谈不上去用了，惭愧。 一个Class要有属性和行为，属性是对状态的描述，而行为是对属性进行改变所做的一些操作。当前项目中也有太多的残缺类（一个实体类中只有getter和setter 方法，基本上没有什么行为，故曰残缺类）。 我们来看一下 java.util.ArrayList.java，该类中的属性只有一个： transient Object[] elementData; // non-private to simplify nested class access 其他的像grow()、indexOf()等方法都是对该属性的操作，而且方法数远远大于属性，这才是一个正确的类，我们要对属性进行深入分析，发掘其一系列行为，让其变得高内聚、松耦合。 2、领域驱动设计思想及发展 2004年Eric Evans在其书中《领域驱动设计—软件核心复杂性应对之道》提出了“领域驱动设计(简称DDD)”的概念。 此后一批专家陆续出版了DDD相关的书籍，丰富了领域驱动设计的实践，其中有<Applying Domain-Driven Design and Patterns> <Domain-Driven Design Quickly> <Domain

开篇 距离发布上一篇该系列的文章好像已经过了快一个半月了，好吧，我托更了😭。一晃就已经到了3月份，在这樱花🌸盛开的季节，终于得重新连载该系列了。在停更的期间时不时会收到大家关于DDD的留言和问题，一旦我有时间一定会回复大家的问题。在此，衷心感谢大家对本系列文章的支持😄。 概述 在实践领域驱动设计（DDD）的过程中，我们往往会遇到多个领域对象相互交互的情况。比如聚合根A在执行某操作之前需要得到聚合根B的某个信号（或某些数据）。如果在单体应用程序中，我们有条件和机会使得两者进行强引用来完成操作，但是这将直接打破领域驱动设计的规范，从而使得项目不可控，再次回到 大泥球 的开发。 现在，咱们可以选取一种更纯净的方式来解决这类问题，并且还能够更清晰的描述领域对象的活动迹象。这就是咱们今天的主题 ———— “领域事件” 。那么到底什么是领域事件呢？引入领域事件会为我们已有的DDD项目带来哪些益处？是否一定要使用领域事件呢？ 本文将从不同的角度来带大家重新认识一下“领域事件”这个概念，并且给出相应的代码片段（ 本教程的代码片段都使用的是 C# ，当然思想是跨越任何编程语言的 😀）。 什么是领域事件 在原著 《领域驱动设计:软件核心复杂性应对之道》 其实并没有直接提及到关于领域事件的介绍。领域对象是在后期才被作者 Evans 提出，经过 Udi Dahan （Nservicebus作者）和

前有幸拜读过诸多大神关于DDD的实现落地等文章，学习较多，受益匪浅，在此推荐 : https://www.cnblogs.com/hafiz/p/9388334.html https://blog.csdn.net/k6T9Q8XKs6iIkZPPIFq/article/details/78909897 https://www.cnblogs.com/netfocus/archive/2011/10/10/2204949.html https://blog.csdn.net/bluishglc/article/details/6681253 下面参考了DDD官方的结构，总结了前辈们的相关经验，再根据自身对微服务和DDD学习和理解，做了一个用SpringCloud搭建的最基本的结构例子。个人才疏学浅，如有雷同或是不当之处，望各位大佬见谅和帮忙指正。 首先引经据典 , 参考官方架构草图，DDD总体结构分为四层 : Infrastructure(基础实施层)，Domain(领域层)，Application(应用层)，Interfaces(表示层，也叫用户界面层或是接口层)，各个层面的作用下面介绍。 　　　　　　　　　　　　　　　　　　　　　　　　 　　　　　　　　　　　　　　　　　　　　 对于DDD的设计而言，最重要的是如何去划分领域，划分好边界。在代码设计上，之前有看到过大佬用模块

本文首发于 vivo互联网技术 微信公众号 链接： https://mp.weixin.qq.com/s/gk-Hb84Dt7JqBRVkMqM7Eg 作者：张文博 领域驱动设计（Domain Driven Design，DDD）其实并非新理论，大家可以看看 Eric Evans 编著的《领域驱动设计》原稿首版是2003年，距今已十余年时间。与现在的分布式、微服务相比，绝对是即将步入中年的“老家伙”了。 直到近些年微服务理论被提出、被互联网行业广泛使用，人们似乎又重新发现了领域驱动设计的价值。所以看起来也确实是因为微服务，领域驱动设计才迎来了第二春。 不过我发现大家对DDD也存有一些误区，使其渐渐成了一门“高深的玄学”，随之又被大家束之高阁。我本人在过去两年多的时间里，研读过多本DDD相关的经典论著、也请教过一些资深DDDer，并在项目中实践过。 不过在初步学习、实践之后我又带着疑问与自己的思考重新读了一遍相关的著述理论。逐渐领悟到DDD作为一种思想，其实离我们很近。 我把自己的学习过程、思考编写成系列文章，与大家一起探讨学习，希望大家能够有所收获，当然其中不正确的地方也欢迎大家批评指正。 同时，在文章中我也会引用相关的论著或者一些我认为不错的案例素材，权当是我们对这些知识的详细诠释，在这里一并对这些DDD前辈的不倦探索表示感谢。 （DDD相关的经典论著） 一、关于DDD的误区

本文首发于 vivo互联网技术 微信公众号 链接： https://mp.weixin.qq.com/s/gk-Hb84Dt7JqBRVkMqM7Eg 作者：张文博 领域驱动设计（Domain Driven Design，DDD）其实并非新理论，大家可以看看 Eric Evans 编著的《领域驱动设计》原稿首版是2003年，距今已十余年时间。与现在的分布式、微服务相比，绝对是即将步入中年的“老家伙”了。 直到近些年微服务理论被提出、被互联网行业广泛使用，人们似乎又重新发现了领域驱动设计的价值。所以看起来也确实是因为微服务，领域驱动设计才迎来了第二春。 不过我发现大家对DDD也存有一些误区，使其渐渐成了一门“高深的玄学”，随之又被大家束之高阁。我本人在过去两年多的时间里，研读过多本DDD相关的经典论著、也请教过一些资深DDDer，并在项目中实践过。 不过在初步学习、实践之后我又带着疑问与自己的思考重新读了一遍相关的著述理论。逐渐领悟到DDD作为一种思想，其实离我们很近。 我把自己的学习过程、思考编写成系列文章，与大家一起探讨学习，希望大家能够有所收获，当然其中不正确的地方也欢迎大家批评指正。 同时，在文章中我也会引用相关的论著或者一些我认为不错的案例素材，权当是我们对这些知识的详细诠释，在这里一并对这些DDD前辈的不倦探索表示感谢。 （DDD相关的经典论著） 一、关于DDD的误区

【第一部分】运用领域模型 第1章：消化知识 有效的建模要素 （1）模型和实现的绑定 （2）建立了一种基于模型的语言 （3）开发一个蕴含丰富知识的模型 （4）提炼模型 （5）头脑风暴和实验 【学习心得】：千万不要用自己有限的思维规划完整的图形，持续学习、消化、输出（讨论）、沉淀，所有道理都是一致的。 第2章：交流语言与使用 模式：UBIQUITOUS LANGUAGE（通用语言） 术语的交集产生了UBIQUITOUS LANGUAGE 想要创建种灵活的、蕴含丰富知识的设计，需要一种通用的、共享的团队语言，以及对语言不断的试验——然而，软件项目上很少出现这样的试验。 如果语言支离破碎，项目必将遭遇严重问题。领域专家使用他们自己的术语，而技术团队所使用的语言则经过调整，以便从设计角度讨论领域。日常讨论所使用的术语与代码（软件项目的最重要产品）中使用的术语不一致，甚至同一个人在讲话和写东西时使用的言语也不一致，这导致的后果是，对领域的深刻表达常常稍纵即逝，根本无法记录到代码或文档中。翻译使得沟通不畅，并削弱了知识消化。然而任何一方的语言都不能成为公共语言，因为它们无法满足所有的需求。 【学习心得】：在自己有限的项目经验里，说沟通成本占据项目总成本的八成都不为过，就像本书一开始的重点，就是无处不在的语言。这语言可以是人话、可以是图形、可以是表格，重点在于可以帮助项目高质量高效率的落地

领域驱动设计(DDD) - HackerVirus - 博客园 https://www.cnblogs.com/Leo_wl/p/3866629.html 领域驱动架构（DDD）建模中的模型到底是什么？_领域模型,DDD_zmh458的博客-CSDN博客 https://blog.csdn.net/zmh458/article/details/96151607 面向服务和面向领域的不同 https://www.jdon.com/45994 避免滥用http状态码，如何将后端业务错误准确地传递到Restful客户端？Spring Boot和JAX-RS的RFC-7807问题详细信息 - codecentric https://www.jdon.com/53707 我在编程20年中学到的5件事 - DaedTech https://www.jdon.com/53432 为微服务构建服务网格的Istio自身却走向微服务的反面单体架构 – Christian Posta https://www.jdon.com/53703 幽默：什么是框架？营销词语背后的真实意思 - Ambrose Bierce https://www.jdon.com/53704 如何设计最佳的微服务架构 -DZone https://www.jdon.com/53706 批处理最佳实践 - Vlad Mihalcea

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

概述 这是关于领域驱动设计的一个系列博文，目的是在学习之后能够使用领域驱动设计的知识来开发应用。 领域驱动设计是目前比较火的概念，其实早在2004年的时候 Eric Evans 就提出了领域驱动设计。但是直到后期才被大家所认识，特别是随着现在微服务的兴起，许许多多的人意识到了领域驱动设计的好处，认为它是指导微服务设计的一把利器。 还记得最初接触到DDD的时候，还是在软考的时候，系统架构设计师教材的某一处提及到了这个词语，然后我就利用搜索引擎一顿查找，想看看这到底是个什么东西。后来，看了 Eric Evans 所写的 《领域驱动设计》 一书，当时感觉书中很多内容有点难懂，整个过程就像囫囵吞枣，以至于后来也踩了不少的坑。 所以就想着能不能将学习的过程记录下来，这也是我写这些博文的初衷。 该系列文章以一个旅行记账的案例为线索，然后慢慢的让它与领域驱动设计思想所融合，最后编写为确确实实的应用程序。哦对了，该系列的代码都是基于 DotNet Core。它最终将呈现为一个Aspnet Core所开发的单体应用，而后期在另外的系列中，我们会尝试将它演变为微服务应用。 因为时间的关系，所以这些文章我尽可能的保证一周更新一篇吧。还有就是鄙人的能力有限，可能文章中有许多错误的地方或者错误的观点，还请您多多包涵，不吝赐教。 下面是为大家提供的博文目录，可能计划博文和实际博文有些差异，还请大家谅解。 目录

学习网址： EntityFramework之领域驱动设计实践 - 前言 EntityFramework之领域驱动设计实践（一）：从DataTable到EntityObject EntityFramework之领域驱动设计实践（二）：分层架构 EntityFramework之领域驱动设计实践（三）：案例：一个简易的销售系统 EntityFramework之领域驱动设计实践（四）：存储过程，领域驱动的反模式 EntityFramework之领域驱动设计实践（五）：聚合 EntityFramework之领域驱动设计实践（六）：模型对象的生命周期 - 工厂 EntityFramework之领域驱动设计实践（七）：模型对象的生命周期 - 仓储 EntityFramework之领域驱动设计实践（八）：仓储的实现（基本篇） EntityFramework之领域驱动设计实践（九）：仓储的实现（深入篇） EntityFramework之领域驱动设计实践（十）：规约（Specification）模式 EntityFramework之领域驱动设计实践【扩展阅读】：服务（Services） EntityFramework之领域驱动设计实践【扩展阅读】：CQRS体系结构模式 学习心得： respository层(仓储)： 不仅仅是进行数据库CRUD操作，且解耦领域模型与技术架构，如果没有仓储层