第一次接触领域驱动设计DDD还要追述到2014年的一次面试经历,虽然在当时自己已经工作年头不短了，但是当时主流使用的架构还是MVC架构。记得面试官问我，作为后台开发，你们会如何去实践后台服务架构的落地？ 我当时想当然的就是说，我们使用敏捷开发，我们使用MVC分层架构，快速迭代。面试官说如果是复杂系统呢？难道没有考虑过使用一些成熟的方法论？比如领域驱动设计DDD？ 当时真的比较尴尬，做了多年后台开发，现在被人质疑自己不懂不会后台开发的方法论。 面试结束以后，我疯狂的百度DDD到底是个什么鬼？初步了解以后立马购买了大神Eric Evans写的《领域驱动设计》，从中学到了太多软件开发的真谛，随后也开始积极地运用在实践中。
这么多年过来了，实际上在工作中使用DDD还是屈指可数，DDD真正用起来了吗？其实没有，我们只学到了它的思想，却很少按照它的方法去实践？原因其实是各种各样的，比如忙着开发新项目，如何快速编码开发系统、快速上线才是王道，领域驱动很好，但是速度上来说太慢了，并且早期时代，业务也并没有那么复杂，DDD远远发挥不出应有的优势。随着现代软件系统复杂度的迅速膨胀，传统的开发模式已经很难适用了。
在计算机软件领域，一直存在一种说法，我们的软件系统，不管大小，规模，其实随着迭代的进行，系统一直都在持续退化。特别是随着业务的复杂度越来越高，导致出现以下情况:
- 系统过于复杂，难以理解，需要花很长的时间才可以搞清楚；
- 随着业务复杂，导致整体设计过于复杂，没法清晰使用架构图展示，可能是过度设计，可能是组件太多；
- 无法进行快速迭代，每次新功能，牵连的地方特多，风险高，甚至改不动,累积大量的系统风险；
- 传统加速方法已经不起作用，不能够通过增加人力资源来解决。或者增加人不能带来时间和效率上的提升，或者ROI特别低；
- 因为高性能，高可用，低成本，安全，规模等因素带来的额外的复杂度，总结来讲，就是非功能性体验带来的系统复杂度；
那么面对退化的系统，复杂度高的系统，我们就只能束手就擒了吗？ 当然不是，这个时候运用DDD就可以帮你彻底或者部分解决软件系统复杂度问题。DDD是软件核心复杂性的应对之道
运用DDD，当系统业务变得越来越复杂时，将我们对业务的理解绘制成领域模型，可以正确指导软件开发。当系统变更时，将变更业务透过领域模型，还原到真实世界，再根据真实世界去变更领域模型，根据领域模型的变更指导程序变更，就能做出正确的设计，从而低成本地持续维护一个系统。这对于如今生命周期越来越长的软件系统来说，显得尤为重要。
最近几年，微服务和微服务架构被越来越多的公司和开发者推崇，不管大公司，小公司都在拥抱微服务。诚然，微服务架构本身确实也带来了全新的开发模式，它恰恰能够帮助很多行业很好地应对互联网业务。很多公司和开发都加入了微服务转型的滚滚洪流之中。
但是，微服务也不是银弹，它一样存在很多的“坑”。
当按照模块拆分微服务以后才发现，每次变更都需要修改多个微服务，不但多个团队都要变更，还要同时打包、同时升级，不仅没有降低维护成本，还使得系统的发布比过去更麻烦，真不如不用微服务。难道是微服务不好吗？
微服务关键在于微，微我们可以理解为小，但是一味的小就能解决问题吗？当然不对，微服务应该是小而专，特别是专，就是要“独立维护”，也就是尽量让每次的需求变更交给某个小团队独立完成，让需求变更落到某个微服务上进行变更，而不需要牵扯到其他上下游系统，唯有这样才能发挥微服务的优势。用架构设计原则上，就是对应的高内聚低耦合原则。
通过一番分析，最终发现微服务的设计真的不仅仅是一个技术架构更迭的事情，而是对原有的设计提出了更高的要求，即 “微服务内高内聚，微服务间低耦合” 。如何才能更好地做到这一点呢？答案就是DDD。
说了这么多，既然DDD这么重要，那到底什么是DDD，怎么在实际工作中应用DDD呢？ 接下来的章节 我会带来进入DDD的世界，并且通过我个人的一次创业经历中DDD的具体实践，向大家介绍DDD的核心概念，结合实际例子讲解运用DDD应对解决微服务架构和开发中的复杂度
- 第一部分:介绍DDD的核心概念；
- 第二部分:如何在微服务架构中运用DDD进行系统设计和落地；
- 第三部分:总结下DDD的核心理论，并谈谈我对DDD的认知和一些经验总结；
