roykingw的专栏

​ 本专栏到这里，也就进入了尾声。实际上，DDD从2004年就被提出，多年来经过很多大神的研究与分享，DDD已经从高高在上的理论空间慢慢沉淀到了我们身边。业界对于DDD的难点，也从学习理解，下沉到了落地实践。就像专栏开篇所说的，这个专栏并不是DDD的布道文，而只是作为一个载体与大家分享我对于DDD的理解。最后这一讲，就基于我自己的理解谈谈DDD落地时需要注意的几个地方。要认识到DDD的不足​ DDD基于多方面的考虑，设计出非常多的设计原则。这些条条框框多了，很多人在实践时，就总是在担心或者犹豫这是不是原

​ 上一讲我们重新回顾了DDD在代码设计层面的指导。通过讲解DDD的多种架构模型，解决了"DDD是什么?"的问题。DDD本质上并不是一个全新的技术或者框架，他也是和MVC架构一样，对业务逻辑进行编排和重组后形成的一种逻辑结构。最后，也提出了一种比较直接的DDD代码设计指导方式，就是菱形架构。但是还只介绍了菱形架构是什么，还没有介绍菱形架构到底如何指导程序设计。这一讲，我们将通过讲解菱形架构之间如何协作的问题，来集中解决"DDD到底干什么"的问题。DDD视角下的微服务​ 我们这一讲是对DDD进行重新审视，

​ 专栏写到这里，不知道你对DDD的理解是什么样的？本专栏从一个最具体的转账功能说起，以代码推演的方式引出了DDD的三层架构，相信由此延伸出来的DDD的概念都能够帮你对于DDD有个比较清晰的概念。DDD并不是凭空产生的，他只是对代码结构进行推演的过程中沉淀下来的一种方法论。但是当DDD从一个具体的技术架构往更上层的微服务架构以及中台战略延伸的过程中，专栏又提到DDD又要不断的进行变化。这个时候你是不是又会觉得DDD有点虚无缥缈了？专栏前面好几次提到，DDD是面向变化的一种软件设计方式，DDD到底是如何来把控

​ 上一讲分享了我关于中台的理解，最后部分也给你留了个问题，怎么设计支付风控系统的统一数据存储功能。不知道你的想法是怎样的？这一讲会分享我设计的一个方案，当然，这方案并不一定是最优的，也并不是实际项目中的方案原貌，只是和本专栏中的其他示例一样，为了加深对DDD的理解而设计出来的。你在看这一讲的过程当中，不妨和我的方案做下对比，并结合专栏前面的知识点，加深对DDD的理解。问题分析​ 我们先回顾下这个统一存储的问题：​ 之前分析过，统一存储服务这一部分的难点主要有两个。一是需要与多种数据源进行对接。例如

​ 这一讲将会要讲解如何从DDD的角度来看企业的中台建设。中台，是国内互联网中，继微服务之后又一个火热的概念。从2015年阿里提出"小前台+大中台"的概念后，中台成了国内微服务实施过程中绕不开的一个目标。但是，虽然中台的实施如火如荼，但是关于中台，依然是雾里看花，一百个人会有一百种理解。关于中台的知识，即使单独拉出一个专栏出来，也不一定能说得清楚，所以这篇专栏中不会去做过多讨论。这一讲关于中台的讲解也跟这个专栏的一样，只是作为一个载体，来分享我在参与了多个中台项目建设后的一些心得与体会。​ 但是，在这其中

​ 上一讲中，针对支付风控系统，使用DDD的事件风暴，我们设计出了一个简单的领域模型。这一讲将会介绍如何使用DDD的领域模型来指导微服务架构设计。微服务拆分原则​ 微服务的技术架构其实并不是很难，SpringCloud技术体系已经很好的涵盖了微服务实现以及运维的方方面面。但是，很多软件开发团队在进行微服务转型时，会把关注点过多的集中在对微服务技术架构的学习上。然而，当他们真正开始将微服务落地到具体的业务时，会发现，微服务架构落地真正的难点是在微服务拆分上。针对一个固定的需求，开发团队大都能够根据自己的经

​ 上一讲中，讲解了如何在软件架构的层面使用DDD来帮助我们设计出"高内聚、低耦合"的高质量软件，希望你能够对DDD的落地实践有个完整的蓝图，并能够在一些具体项目中大胆的进行实践，来完善DDD的其他细节。​ 同时上一讲中也提到了，当应用进入微服务阶段，DDD将会体现出更大的作用。而对于微服务系统，最核心的难题其实是微服务的拆分。不合理的拆分方式不但不能提高研发效率，反而会加大系统的维护成本。因此，微服务的设计不是简单的应用拆分，而是对设计提出了更高的要求，需要更高效的"高内聚、低耦合"。而经过多年的实践，

05、深入DDD的核心：领域与限界上下文​ 上一章节中，我们主要讨论了DDD如何通过仓库、工厂、聚合这些工具，来保护以实体、值对象和领域服务为主体的领域模型的。通过仓库和工厂隔离了底层数据存储模型对领域模型的影响。而又通过聚合，隔离了业务对领域模型的影响。这样，领域就可以以一个相对独立的方式进行演进了。其实重点就是提出了一个聚合自治的思想。将一个大的问题划分成多个相对独立的聚合，减少各个聚合之间的依赖关系，从而使各个聚合能够以比较独立的方式进行演进。​ 然而，如果站在更大的业务系统，例如电商网站的角度，

04、DDD如何保护领域模型​ 上一讲中，我们已经提到了领域服务、实体和值对象的重要性，基于这些基础对象，就能够形成一个基础的领域模型。我们对这个领域模型进行一些贫血模型和充血模型的设计，就能搭建出一套基于领域模型设计的应用架构。这种应用架构由于功能相对内敛，所以很容易设计出“高内聚，低耦合”的高质量应用。但是设计出这样的基础领域模型其实还只是第一步，在后续领域模型具体落地的过程中，以及后续的业务需求迭代过程中，如何保护领域模型不退化，依然有很多问题需要解决。而这些问题，光靠领域模型本身是远远不够的，还需

你好，我是王良翼。在这个专栏中，你将跟我一起学习DDD(领域驱动设计)以及如何将这种抽象的架构思维方式进行落地实践。一、什么是DDD？​ 这其实并不是一个新奇的概念。在2004年，著名建模专家Eric Evans发表了一本非常有影响力的巨著：Domain Driven Design - Tackling Complexity in the Heart of Software(中文译名： 领域驱动设计-软件核心复杂性之道，2006年3月由清华出版社出版中文译本)。在此书中就系统性的提出了DDD(领域驱动

​ 在上一节专栏中，我们将一个MVC架构的支付功能推演成了DDD架构，其中引入了很多DDD中的概念。像领域服务、实体、值对象、防腐层、贫血模型、充血模型等。但是过程毕竟比较匆忙，还无法理解DDD如何在方法层面指导应用架构设计。这一节，我们就来仔细讨论下在DDD落地过程中，应该怎么样来设计这些基础的概念。贫血模型 vs 充血模型​ DDD与传统MVC最为明显也是最为具体的区别就是底层的这两种设计思想，贫血模型 和 充血模型。​ 贫血模型基于一些非常简单POJO对象来构建整个应用，这些POJO对象在jav

你好，我是王良翼。​ 我们前面花了不少篇幅来分析软件老化的问题，也提出了DDD可以有效的防止软件老化。那DDD到底是如何来防止软件老化的呢？我们今天这一讲就以一个互联网最为常见的电商支付场景为例，来理解下基于DDD的应用架构。业务案例说明​ 我们先来看一个简单的需求案例：用户购买商品后，向商家进行支付。​ 当开发人员接收到这样的需求时，会尝试对这个支付动作进行拆解，最终确定出如下的步骤：1、 从数据库中查出用户和商户的账户信息。2、调用风控系统的微服务，进行风险评估。3、实现转入转出操作，计算

你好。我是王良翼。​ 关于DDD，之前已经简单做过介绍，即Domain Driven Design。那这里怎么又多出了一个DDD呢？其实另一个DDD是我抽象出来的一个概念，即我们设计系统时最常用的一种数据驱动设计的方式：Data Driven Design。事实上，这就是我们常见的两种设计方法，那这两种设计方法到底有什么不同？又是怎么引领架构潮流的呢？​ 关于DDD领域驱动设计，自2004年就提出，但是很长一段时间内，却并没有太多的反响。因为在DDD推出之时，国内的软件业还刚刚起步，软件系统也都处在单体