领域驱动设计

我在上一篇说了下我在DDD实践过程中的一些想法。要长期实行DDD的话，领导的支持、人才的培养、领域专家的协助等，都是不可缺少的。很多情况下，我们都无法有这么好的条件。那是不是说，就没什么意义去学习领域驱动设计了呢。其实不然，且听我分析。 我本人兴趣广泛，喜欢东学一点，西学一点，偶尔捣鼓点小东西，自娱自乐下。但是对于一些枯燥的原理东西又不是特别感兴趣，这就导致了很多技术都是懂个皮毛，不深入。所以要往技术架构、技术专家发展就带来了一些困难，于是就想着往业务架构方向发展。只是网络上找了个遍，也很少介绍有关业务架构是能力怎么发展的书籍。后来想了想，业务专精的技术人员，因为受限于从事的行业业务，经验无法在其他行业通用。（这也是想往业务架构发展的技术人员一个要考虑的点。可能后续找工作会成问题。面试的一看是业务架构，偏向业务，要是和公司业务不符，可能直接PASS）。 后来接触了DDD后，了解了其背后的思想，才让我对业务分析这方面有了一定的进步。下面我就说说自己从DDD中学到的。 共识 业务专家不懂技术，技术不动业务，产品就作为了技术和专家中间的桥梁。可产品也有自身的问题，并非每一个产品都能对业务了如指掌，对技术的理解也止步于懂个大概。产品在传递一些信息和概念的时候，多少会参杂自己的理解，有的甚至是曲解。为此，DDD的做法是让专家、产品、技术一起参与项目，一起讨论。其中一个目的是能让项目成员都对业务中的一些定义、名词等达成共识。只有这样才能消除沟通带来的歧义，这也是对业务进一步分析的基础。 一个简单的例子，“订单”这个词不算陌生，但是在一个电商系统中出现“订单”字眼的地方很多，仓储系统、物流系统、交易系统、支付系统等。但是对于不同系统，具体应该是不同的领域，不同的上下文中，“订单”的概念是不同的，有些系统还会出现多种“订单”定义。比如，对于支付系统，就有支付订单和交易订单，而交易订单更多的只是一个与外部关联的值而已，支付订单才是它的业务核心。理清这些内容，建立统一语言，让团队对业务达成共识，这是DDD的思想之一。 从产品经理角度看业务 我很想说从领域专家的角度去看业务，不过这个确实很难做到的。 在了解DDD之前，我从没听过用户旅程、用户故事、事件风暴之类的名词，对产品经理如何分析业务也是一无所知。大部分开发基本都和我一样，对业务的理解都是来自现有代码和产品经理对业务的描述。代码本就是开发写的，而产品经理也不会把自己怎么分析业务的过程对开发说的很详细。这样，开发理解的业务就是很片面，很局限。当问及“某某接口是做什么的”这样的问题时，开发更多的回答就是，这个接口提供了什么样的功能，却无法回答上层的业务是如何的，接口在整个业务场景中的作用是什么。 要理解整个业务，就必须换个方式，换个角度去看业务。如果自己是产品经理，需要给开发讲解业务，能讲解清楚吗？如果自己从零开始分析、设计这款产品，又会怎么做？产品经理那些分析业务的方法自己是否可以学，可以用呢？只能说这样的转换是一个漫长过程，这找不到什么快速的学些方法，我自己还在慢慢摸索。也许有一天，不愿意做开发了，可以做一个懂技术的产品经理。 领域模型 开发不喜欢写文档，写出来的也不怎么靠谱。开发间通用的可能就是各种UML图和架构图这些。只是这些图都不能很好的反应业务，也是导致业务分析结果无法长时间留存和随业务发展而演进。 DDD需要产出领域模型，他是业务的抽象结合技术后的产物。他对开发更友好，虽然丢失了业务细节，但依然能很好反应业务。个人觉得，将领域模型作为整个迭代过程的中心，领域模型前是对业务需求的具体分析，确定领域模型后就是开发在它基础上做技术实现。领域模型也成为后续开发理解业务的一个起点。 从领域模型到代码模块 这个好像没啥好说的，到了实现这部，看的就是个人编码能力了。 DDD的学习，对技术的提升很有限，更多的是在提升对业务的分析能力。这个能力不局限于某一行业或领域，它是通用的。深入学习，以后怼产品、忽悠领导就全靠它了。

最近在找工作，深知自己没多少斤两，也只能苦刷八股文。不过在很多招聘的信息中看到了领域驱动设计这个关键词。刚好之前公司实践过这个，也许这个是可以在面试中吹吹的东西。于是乎就努力回想了下之前的经历，希望能整理出点有用的东西。 领域驱动设计，简称DDD，说它是设计思想也好，方法论也好，哲学也好，最后的目的就是让代码能更好反映业务，同时还能控制业务和系统的整体复杂度。其实吗，各种架构、模式、模型什么的，都是在控制复杂度，因为这些复杂就是生产效率的敌人。 以往，如果让我去梳理一个复杂的业务系统。我肯定在了解业务后，提供各种解决的技术方案，然后就是重构。等重构完，确实整个系统的代码会干净、整洁很多。讲得高大上一点，就是耦合度低了，内聚高了，接口设计更合理了，代码可读性也高了。可是当几个迭代版本后，就会发现，似乎有慢慢的回到之前的模样了。这里的两个重点就是，第一、我们的改造方案虽然是基于业务，但是更多还是基于技术角度思考；第二、我们的代码无法一直保持这个良好的状态。我们的工作就在迭代、重构、迭代，再重构的循环中。那如果不重构呢，对于那些还在高速增长的业务系统，忽视技术债务，最终也只会把开发拖入泥潭。 DDD的目标就是解决代码无法随业务模型同步调整的问题。通过维护一套领域模型，让代码随着这套模型一起演进。新的业务功能进入系统时候，需要先融入到这套模型中，才考虑代码的实现。 听上去，除了DDD理念中的统一语言、划分领域，以及一些花哨名词和概念外，并没有什么新花样。其实很多高级开发或架构师，都在做差不多的事情，分析业务，然后根据业务对系统架构和代码做调整。问题是，很多开发留下了最后系统调整的方案，却没有将分析业务的成果留存，或者留存了也没有在后续持续更新，更别说以业务模型作为开发设计的中心。DDD则在需求设计、业务分析、领域模型设计、代码实现等各阶段，提供了一套行之有效的方法。保证领域模型紧随业务变化，代码符合领域模型。 扯了那么多，还是谈谈之前的落地经历吧。说叫落地实践，实际就是摸着石头过河。翻遍了网上的资料，除了大牛那两本后后的书外，很难找到完整的落地方案。很多就介绍了个大概，也没有了啥后续。所以实践就变成了摸索。相对于战略设计，战术设计可能是开发最擅长的，只要在摸清业务，确定领域模型的前提下，战术设计完全可以有开发单方面完成。那战略设计就成为了实践中的重点。团队还是选择了事件风暴这种方式来分析业务。事实也证明“事件风暴”确实很有效果。从事件和用户旅程出发，能很快让开发了解完整的业务。同时挖掘业务流程中，一些不怎么被开发关注的内容。分析完成业务后，后续就是划分领域和上下文，以及模型设计等工作。这个过程也是反反复复的，毕竟对于复杂系统，很难一次性掌握。 DDD的好处，网上随便找一篇文章都能说出一堆来。只是对于落地的难处却说的比较少。我这里就说下过程中遇到的难点。 第一、领域专家难寻 DDD的要求就是和领域专家一起来梳理业务。我们团队刚好在一个比较传统的，或者说行业内业务很成熟的系统中实践DDD，加上公司确实有这方面资源，可以轻松和领域专家一起工作。同时开展DDD实践的另一个团队，那就没这么好运了。对于互联网行业，很多新兴的业务，都是靠着一群富有创新力的人才创造出来的。领域内并没有专家可以找，唯一对业务了解的恐怕就是产品经历了。这种情况下，分析业务就完全靠开发和产品自己对业务的理解了。还有就是领域专家是甲方的，也很难说动甲方参与设计和讨论，特别DDD的模式下，需要长期参与其中。 第二、老板或领导的意愿 很多领导或老板，脑袋一热，就要上DDD，可能并没有了解清楚。当时DDD实践是，就会无形中拖慢整个开发流程。毕竟，对核心业务的每一次调整，都要从需求开始，在业务层面梳理清楚。不像以往的上来就写代码的模式。那些头脑一热的领导，往往会被劝退。在没有上级的支持的情况下，DDD是很难维持的。特别处于长期工期紧张的团队。 第三、人才储备 系统不断的迭代，DDD也不是一锤子买卖。必须有人来负责管理，让团队可以持续进行。团队的其他成员也需要有能力，有意愿支持这种形式。特别是在工期压力大的团队，很可能团队选择逃避这种复杂的设计方式。这种情况下，核心成员的离开，很可能导致后续没有人能接手，从而放弃DDD。 第四、没标准，没最佳实践 网上很多都是说自己实践过，但是也没说持续多久，效果如何，哪些问题，怎么解决这些问题。更谈不上最佳实践了。而DDD本身是方法论、是思想，并没有对过程和产物做标准化定义，那不同团队设计出来的方案各不相同，这也导致了很多东西无法有效推广。 以上都是我个人的一点想法。本人经验有限，可能很多考虑不成熟的地方。