从OO到DDD

        分而治之作为控制复杂性的技巧由来以久。在设计复杂系统时，先分解为一些小的部分，然后独立的处理每个部分，再将他们连接起来以完成实际工作。要理解某一部分，只需要了解这部分相关的内容即可，而非所有内容。这些设计方法可以分为三类：自顶向下的结构化设计，数据驱动设计与面向对象设计。结构化设计是面向数据流的设计方法，结构化设计希望程序的结构尽可能反映要解决的问题的结构，将计算逻辑封装在结构以外的单元中。如果我们以这样的方式设计一个订单系统，很有可能是这样的：

摘自《重构》

        这种设计方法在计算受限的20世纪七八十年代，问题域还没有那么复杂，是很有效的，但当代码量超过10万行时，结构化方法就会带来问题，对于复杂度的控制就有一些力不从心了，很容易设计出大泥球架构。在这样的背景下，OO开始逐渐流行起来，它基于问题领域的关键抽象概念对系统进行分解，并封装软件系统内在复杂性。基于OO方法设计的订单系统如下：

摘自《重构》

        不管是过程式还是OO分解，都针对要解决的问题做了抽象，区别是抽象的角度不同，过程式是以数据为中心，而OO是将问题分解成领域内的关键概念，通过概念之间的协作完成工作，算法封装在概念之下。OO的分解问题的方式更加接近人类思维，也简化了系统设计。就这样OO成为设计系统的优选实践，开发者似乎找到了银弹，在实践中开始大范围的使用，但遗憾的是开发者并没有将关注点从数据转移到领域上，大部分开发者还是打着OO的大旗愉快的写着过程式的代码，驾驭复杂问题的痛点也没有根治。

        随着OO设计模式与设计原则的提出，在实践OO方面给了更强的指导。有了模式，我们就能记录那种己知反复出现的问题以及特定上下文对它的解决方案。就这样我们掌握了更丰富的套路和技巧，站在了无数巨人的肩膀上构建系统，华丽的设计在项目中随处可见，但是对复杂问题的驾驭依然像大山一样矗立在那无法逾越。开发人员也并没有停止吐槽系统太烂，PM依然抱怨开发工作进展太慢，测试的范围还是难以控制，团队在承担的压力似乎没有减少。

        进入互联网时代以后，传统企业开始向互联网化过渡，微服务随之兴起，合理的规划微服务与设计服务间的通信策略成为成功实践微服务的关键能力。DDD这瓶沉年老酒被更多的开发者重新拾起，它以从问题域入手，先分解领域内的关键概念，再为关键概念建立联系，设计实践方案。从战策到战术提供了一整套可操作的方法成为了微服务建模与设计的最佳实践。

        在DDD的指导下，系统设计过程重回OO本质，问题域成为建模与设计的焦点。以业务能力为中心组织的微服务也开始逐渐发挥它的优势，问题领域的复杂性开始变的可控，构建的系统也充分发挥出了OO优势，演进式架构也随之落地。

        DDD是OO DONE RIGHT在实践中也被无数次证明，AKKA Persistence FSM在最初设计时并没有基于DDD这套方法去设计，但是当它以OO的原则下实现后，与DDD的思想惊人的相似。如果你正在基于OO设计与实现系统，去实践DDD开启真正的OO之旅吧。