DDD与面向对象设计

DDD最近几年比较热，由于它在某种程度上确实解决了一些设计问题，它强调在软件设计的初期就引入领域专家，始终围绕着软件要解决的 核心领域问题 来展开，很好的避免了一些架构过分设计，过早的引入非领域问题设计，好比事务，并发。它围绕着几个核心概念——Entity, Value Object, Aggregate, Repository, Domain Service, Domain Event——来设计并实现功能，整个团队用一致的工程语言来描述和组织相关的代码，比较有效率，代码质量也有必定的保证。可是它也有其局限性，我用《面向对象分析与设计》的解密文本的应用来举例子，题目描述很简单，给定一个密文，设计一个解密程序。若是生硬地沿着DDD的思路，咱们发现很难去识别相关的Entity, Value Object, Service并展开相应的设计。对于这样的问题，面向对象设计给了一个很是漂亮的解答，它模拟了一个写了密文的黑板，有众多拥有某些知识的观察者在观察并根据本身的知识——好比单字母在英语中，通常是I或者A；好比三个字母最后一个是E的极可能是THE；好比结尾连续两个字母同样极可能是EE …… ——尝试着解密部分密文，而后通知其余的观察者，从中咱们能够学习到面向对象设计如何针对一个很难入手的问题，经过分解一个一个细粒度的对象，每一个对象只解决一部分小的问题，最终各个对象经过交互，来获得最终的答案，所使用的 Blackboard模型 不在这里展开讲了，有兴趣的读者能够自行深刻了解，很是推荐你们认真学习这个问题解决过程，可以很深切的体会到面向对象设计的思惟。从中咱们能够看出面向对象设计通常不关心数据，它更关心的是行为。一个问题在现实中如何被解决，并经过模拟这个解决过程，定义其中所牵涉到的对象，行为，以及交互，从这方面说，它与DDD是不太相同的。不管DDD如何强调要设计充血的Entity模型，在落地过程当中，识别Entity和Aggregate的阶段很是容易陷入设计出大量贫血Entity的状况，经过setter/getter，而不是清晰的包含领域意义的行为来操做数据；陷入过早的考虑数据之间的关联而不是对象彼此之间的交互的陷阱。

DDD自己并非传统数据驱动设计的变形，尽管数据驱动过去是，如今仍然是一种很是有效的设计方法。

Get the data structures correct, and the code will write itself.

早期的C程序员解决问题，都是定义好相关的struct，详细到xxx字段是用int仍是char，而后围绕struct来开发相关的方法并组织这些方法的调用过程。传统的企业级应用开发也是先作好数据库的设计，整个应用层是围绕着数据库来开发的。说到这里，想扯一点Go语言的语法设计，只是我的感受，由于Go语言的设计者们都是资深的unix c程序员出身，Go语言的面向对象的语法设计是有点别扭的，struct embedding，带接收者的方法定义，带来了继承，多态，覆写概念上的一些理解障碍。

既然谈到了数据驱动设计，就再多说几句Kubernetes和Spring Cloud，如今这两种是常见的微服务架构落地方案了，他们就有很大的不一样，Kubernetes经过定义精妙的Pod，Deployment，Service，DaemonSet，Ingress， CustomResourceDefinition等数据结构，全部的核心组件经过监控etcd的数据变化来调整自身的状态，在不增长复杂性的基础上提供了很好的扩展性。反观Spring Cloud，基于面向对象的设计，提供了一个又一个的抽象，架构的复杂性和扩展性造成了正相关的关系，致使Spring Cloud总体的复杂度愈来愈高。很是佩服Google的Kubernetes的总体架构设计理念以及定义核心数据结构的功力。

DDD是一种自底向上的设计，很是适合企业级产品的团队开发，由于企业级产品绝大多数都是围绕着明确的领域数据来实现功能，并且DDD有不少好的实践与模式帮助解决不少开发过程当中常见的问题。

面向对象设计是一种自顶向下的设计，更普适一点，更难掌握一点，很难概括出有明确的步骤指导解决某一类问题，正如《面向对象分析与设计》中说的同样，在不少状况下，完成详细设计后，识别Entity也是其中的一步，不过是在至关靠后的设计阶段了。

DDD和面向对象设计都是核心领域建模的方法，要完成真正的产品，还有不少方面要考虑。在软件开发领域，还跟多年前的论断同样，没有银弹！

最后，安利两本书，《面向对象分析与设计》和《实现领域驱动设计》