DDD专栏开篇词：关于DDD_ddd开篇-CSDN博客

本文是DDD专栏的开篇，探讨了领域驱动设计（DDD）的起源和在微服务架构中的重要性。作者作为一名有丰富经验的J2EE开发者，通过实例阐述了传统架构在应对复杂业务时的挑战，以及DDD如何提供解决方案。专栏将深入讲解DDD的理论和实战技巧，旨在降低学习门槛，帮助开发者、业务人员和架构师理解和应用DDD。

你好。在这个专栏中，你将跟我一起学习DDD(领域驱动设计)以及如何将这种抽象的架构思维方式进行落地实践。

一、什么是DDD？

这其实并不是一个新奇的概念。在2004年，著名建模专家Eric Evans发表了一本非常有影响力的巨著：Domain Driven Design - Tackling Complexity in the Heart of Software(中文译名：领域驱动设计-软件核心复杂性之道，2006年3月由清华出版社出版中文译本)。

在这里插入图片描述

在此书中就系统性的提出了DDD(领域驱动设计)的概念。然而，DDD的整个架构设计方法在很长一段时间内并没有激起多大的反响。直到最近随着微服务架构的兴起，系统的规模与复杂度开始直线上升，而传统的MVC架构并不能够很好的支撑复杂系统自顶而下的全面设计与落地。软件行业开始急需寻找一种能够全面支撑大型微服务项目设计落地的架构方法论。这时，DDD才开始重归大家的技术视野。越来越多的企业开始积极尝试DDD，甚至将DDD看成是解决软件复杂性的超级战舰。然而，在光明未来的背后，DDD的发展却并不是一帆风顺。一方面，他只是一种高度抽象的方法论，在落地实践上缺乏具体的指导方案，因此，企业如何将DDD完善落地，还是处在八仙过海，各显神通的阶段。另一方面，关于DDD的神奇，业界也还是褒贬不一，争论不断。也因此，才有了这个专栏，来跟大家分享我对DDD的理解。

二、关于DDD的思考

我是一名从业J2EE领域十四年的老兵，在我的从业生涯中，接触到了非常非常多大大小小的软件项目。从基层开发人员到架构师，各个阶段的工作都给我带来了不同的问题，也给我带来了对于软件不同的理解。为了减少不同业务给技术带来的多样性，我们总是会尝试将技术模型给固定下来，希望总结出一些能够在项目之间通用的模型或者方法。单体架构阶段我们会注重封装，希望将不同项目中的一些共性问题抽取出来，封装成能够通用的一些组件。而到了微服务阶段我们会更注重联合，对功能模块的设计都会更专注于平衡封装与扩展。但是这期间，始终有一些共性问题，即便用不同的方式来进行架构设计，都无法找到很好的解决方法。例如对业务的理解永远跟不上业务的变化，经过若干次的版本以及人员迭代后，复杂多变的业务足以摧毁前期任何的设计模型。而某一次迭代埋下的小小隐患，会在以后的多次迭代中，被逐渐的滚雪球，将整个项目代码拖成一个大的泥潭。造成整个项目业务响应缓慢，软件性能下降，最终严重影响用户体验。

例如我曾经接手过一个问题最为严重的商城项目，在前期针对商品单品页的访问性能做了相当多的针对性设计。包括资源懒加载、页面静态化等等非常多的手段。在前期这些设计虽然加大了一点点技术门槛，但是对性能确实有不小的提升，前期压测，抗住几万人的秒杀活动没有任何问题。

在这里插入图片描述

但是像图中这一小部分的选择商品，计算价格的部分，是整个商品单品页的核心功能，在我们原本的设计中，它可以在对商品做单品页发布时就固定下来，是属于变化会比较小的部分。可是在具体实施时，客户方几乎每个月都会提出一些新的功能需求，都会或多或少的影响到这一部分核心功能。营销活动、会员优惠、预售、抢购、推荐评级等等，不断的有新的功能需要或多或少的添加到这一小部分页面中。经过三年左右的迭代后，演变成了一个无比复杂的体系，以至于不得不对这一部分功能前前后后做了三次完整的重构。在某一次计算价格时引入ajax对实付价格进行异步计算开始，不断的有ajax业务逻辑添加到这一部分页面中，使得前期的页面静态化设计基本上形同虚设，页面响应速度非常慢，于是不得不针对性能做重构。再加上每次开发新业务时，老的业务代码无人敢动，造成每隔一段时间，整个代码就会堆积到一个几乎无法开发的程度，于是又不得不针对业务梳理做重构。而项目实施期间的重构，就多次影响到客户的业务体验，因为这些重构，都是不在业务方的考虑范围内的。

类似的问题不断的在各个项目上重演，我们也做了非常多的思考与尝试。最终在看到DDD后，觉得似乎找到了答案。在复杂系统中运用DDD，将业务理解绘制成领域模型，进而用领域模型来指导软件开发。这样业务的变化都可以快速的映射到具体的领域模型当中，这样通过领域模型的指导，就可以以较低成本持续维护一个系统进行演进。这对于如今生命周期越来越长的系统来说，是非常重要的。

在2015年左右，微服务体系逐渐成熟。于是我们又投入了微服务转型的滚滚洪流。但是，在微服务实施过程中，我们发现微服务虽然能够一定程度上减少变化的扩散范围，但是并不能从根本上解决我们之前遇到的问题。微服务项目如何拆分？如何扩展？如何做到"高内聚、低耦合"？依然缺乏足够的方法指导。当项目的复杂性再次上升，各个微服务依然会出现膨胀退化的问题。再加上微服务带来的组织变更、团队变更、沟通成本、运维成本等问题，使得我们不禁开始思考，是不是微服务不好？而DDD的战略设计工具再次让我们的眼前一亮。DDD的架构模型非常好的切合了微服务时代的模块划分问题，对于我们构建微服务体系，以及现在流行的中台架构都提供了非常好的理论指导。于是我们开始尝试在部分项目中实践DDD的架构设计。

三、关于本专栏

但是我们在实践过程中发现，DDD虽然提供了一套完整的理论架构体系，但是在落地实践方面却缺乏具体的指导标准，这造成DDD在落地时间过程中非常容易走形。经过几番探索，我们依然没有找到万能的架构方式，但是对于DDD，却总结出了相当多的经验，于是便有了这个专栏，来跟大家分享关于DDD的经验心得。

这个专栏并不是作为一个DDD的布道文来准备的，而是想要作为一个载体跟大家分享我对于软件架构的思考与理解。在本专栏中，对于DDD的战术工具以及战略工具都进行了详细的理论讲解以及实战演练。对于软件整体设计以及微服务代码落地都有不少的讨论，相信对于开发人员、业务人员以及架构师都能有一定的帮助。

这个专栏并不是作为一个DDD的布道文来准备的，而是想要作为一个载体跟大家分享我对于软件架构的思考与理解。以往DDD更多的是作为架构师的专利，网上很多的专栏教程也都是专门面向架构师、CTO这些高层次技术人员的。而在本专栏中，会适当降低DDD的学习门槛，对于DDD的战术工具以及战略工具都进行了详细的理论讲解以及实战演练。对于软件整体设计以及微服务代码落地都有不少的讨论，力图让开发人员、业务人员以及架构师都能从中得到一定的帮助。

最后，关于DDD的学习和应用，对任何人都不是一个简单容易的过程。他的一大堆概念理解就造成了不小的学习门槛，而在落地实践时的理解，更是仁者见仁智者见智。本专栏只是希望能够尽量轻松高效的帮你跨过DDD的学习门槛，并可以尝试在未来工作当中开始推动DDD的落地实践。同时也欢迎本专栏的留言区分享自己的工作问题和经验，帮助你找到自己的"同道中人"或者"良师益友"。