真正能够产生价值的在于我们当前正在走的路：如何理解我们的业务问题。

本文归纳总结了应用架构的混乱问题，并给出了一些重点需要理解的内容，希望能对大家的日常开发有一些帮助。

本文重点围绕软件复杂度进行剖析，希望能够帮助读者对软件复杂度成因和度量方式有所了解。

了解过 Hex 六边形架构、Onion 洋葱架构、Clean 整洁架构的同学可以将本篇文章介绍的实践方法与自身项目代码架构对比并互通有无，共同改进。没了解过上述架构的同学可以学习一种新的架构方法，并尝试将其应用到业务项目中，降低项目维护成本，提高效率。

架构这个词源于英文里的“Architecture“，源头是土木工程里的“建筑”和“结构”，而架构里的”架“同时又包含了”架子“（scaffolding）的含义，意指能快速搭建起来的固定结构。而今天的应用架构，意指软件系统中固定不变的代码结构、设计模式、规范和组件间的通信方式。在应用开发中架构之所以是最重要的第一步，因为一个好的架构能让系统安全、稳定、快速迭代。在一个团队内通过规定一个固定的架构设计，可以让团队内能力参差不齐的同学们都能有一个统一的开发规范，降低沟通成本，提升效率和代码质量。

在做架构设计时，一个好的架构应该需要实现以下几个目标：

• 独立于框架：架构不应该依赖某个外部的库或框架，不应该被框架的结构所束缚。
• 独立于UI：前台展示的样式可能会随时发生变化（今天可能是网页、明天可能变成console、后天是独立app），但是底层架构不应该随之而变化。
• 独立于底层数据源：无论今天你用MySQL、Oracle还是MongoDB、CouchDB，甚至使用文件系统，软件架构不应该因为不同的底层数据储存方式而产生巨大改变。
• 独立于外部依赖：无论外部依赖如何变更、升级，业务的核心逻辑不应该随之而大幅变化。
• 可测试：无论外部依赖了什么数据库、硬件、UI或者服务，业务的逻辑应该都能够快速被验证正确性。

这就好像是建筑中的楼宇，一个好的楼宇，无论内部承载了什么人、有什么样的活动、还是外部有什么风雨，一栋楼都应该屹立不倒，而且可以确保它不会倒。但是今天我们在做业务研发时，更多的会去关注一些宏观的架构，比如SOA架构、微服务架构，而忽略了应用内部的架构设计，很容易导致代码逻辑混乱，很难维护，容易产生bug而且很难发现。今天，我希望能够通过案例的分析和重构，来推演出一套高质量的DDD架构。

复杂业务系统长期迭代，难免会逐渐腐化，如何治理腐化，并设计出能够延缓腐化，保持长期高效能的方案是一个开发同学难免要遇到的问题，本文旨在介绍一套基于DDD的落地实施方案，提供另外一种解决问题的思路。