复杂软件解决之道DDD概论
随着业务发展，软件本身也需要不断进行迭代以适应业务变换。
我们可以说，软件存在的价值就是映射真实世界，解决业务问题，从而创造更多价值，为大众提供更加便利的服务。
面对复杂业务场景，我们往往通过不断增加业务分支，对原有的冰山一样的代码逻辑进行小心翼翼的修改，生怕因为自己的修改导致全局出现不可挽回的损失。
这种不断迭代的历史遗留代码，几十年前的《人月神话》已经下过一次定义–“焦油坑”。
我们也常常调侃，自己不是在写代码，而是在Ctrl C / V, 在代码的“shit mountain”山不断进行着业务逻辑的搬运，并时刻祈祷系统别出异常，从而成为背锅的那个人。
这种现实是否能够通过一定的方式/方法/技巧改善甚至说这种类型问题能否改善呢？
答案是显而易见的，随着软件行业的发展，在业界不断耕耘的专家/资深工程师，确实总结出了很多软件开发的套路/技巧/方法论，供我们开发者使用，并能够解决一定场景下的问题。
DDD（Domain Driven Development 领域驱动设计）也是其中的一个重要方法论，它作为一种综合的、新生的、不断发展完善的业务领域建模思想，在微服务和服务化大行其道的今天，不断推陈出新，指导新兴软件从零到一落地、辅助复杂遗留业务场景重构。
我们可以说，DDD本质上就是一种复杂软件解决之道，了解并运用DDD提供的思想和方法论，能够帮助我们更好的理解、改善、落地复杂多变的业务场景，并能够让开发者将技术更好的运用到业务场景中，使我们的软件系统更符合面向对象的思路：即在软件系统中映射并还原真实世界。
笔者将在未来的一段较长时间内，将自己在DDD领域驱动方面的学习、思考、落地经验，用一个系列的文章进行分享，并殷切希望能够用通俗易懂、规范的语言，为读者全方位的呈现DDD的魅力。
这个系列将主要分为三大模块：
- 概论，将主要从概念，架构思维，方法论探究，案例浅析等方面对DDD做一个全局的宏观分析和学习
- 实战，将通过一个贴近真实业务场景的案例，对笔者在DDD落地方面的思考进行分享
- 反思，将通过一系列的思考和代码片段，站在业务和技术综合角度，对DDD、架构、编码技巧、职业发展等角度，阐述笔者对DDD本质与架构方面的思考；
三大模块全部落地是一个长期的事情，可能半年，可能一年，也可能更长，但笔者会坚持做这件事。
作为概论部分的首篇，我将主要讲解一下概论系列主要行文思路和纲要，以便为后文详述奠定基础。
思维框架，脉络梳理
图中的橙色部分为内容主干，绿色部分为扩展延伸。
具体分析一下：
- 我将从宏观上讨论一下，究竟什么是DDD，这部分内容没有太多的发挥空间；
- 接着阐述DDD的发展史，凡理论皆有其发展过程，都符合历史唯物主义；
- 讨论一下问什么要用DDD，引出对软件复杂度的思考，并进一步讨论DDD是如何应对软件复杂度的；
- 说到DDD就不得不解释一个概念，“统一语言；我将解释一下什么是统一语言，它有什么作用，并引出DDD参与者；
- 对DDD核心概念进行举例说明
- 对DDD常见分包进行阐述，并解答灵魂拷问：“用了DDD分包就是落地了DDD么？”；
- 详细讨论DDD的本质：通过建模还原真实世界；
- 讨论一下DDD适用场景，新项目/老项目都能应用么；
- 通过一个简单案例，先入为主的表达DDD的编码风格，权当抛砖引玉；
- 回到问题的起点：讨论软件退化的根源；
- 在概论部分的最后，推荐一些自学DDD的资料，以便读者朋友能够进一步深入了解学习DDD；
接下来的文章，我们就会从DDD的历史入手，逐步探寻DDD的魅力。那么就请亲爱的你跟随者我的视角，与我一同领略DDD领域建模的无限精彩吧！
版权声明：
原创不易，洗文可耻。除非注明，本博文章均为原创，转载请以链接形式标明本文地址。
