戏说领域驱动设计(一)——开场

  为什么叫“戏说”呢?领域驱动设计出来的时候就有一种对于受众的调戏。书是读完了,您个人升华到了“看山非山,看水非水”的境界。再看一下落地代码,搞不好会仰天长啸:“这是我写的?”。佛家讲“空”,儒家讲“仁”,领域驱动讲“真”。真者,本质也。当您到了“真”的境界,就不会再与别人争论“到底是java还是C#好”,也不会再纠结“我这个设计合不合理啊?”。很多东西自然而然的就出来了。

  回顾历史,领域驱动设计(Domain-Driven Design,简称DDD)大概源起于2004年。有个洋人叫Eric Evans出了本书叫《Domain-Driven Design : Tackling Complexity in the Heart of Software》(领域驱动设计:软件核心复杂性应对之道)(其实我更关心副标题)。全书大概包含两部分:战略设计、战术设计。战略方面关注如何将大系统划小;战术方面关注划小后的软件如何设计。随着时间的推移,陆续有一些大家对领域驱动中的战术部分进行了补充,比如“命令查询分离架构(CQRS)”、“事件溯源(ES)”等。

  从2004年至今16年+的时间里,按理DDD这套东西早就应该过时了,尤其在是IT圈中。十多年间IT技术变化飞快,很多人连Java8还整不明白,人家已经推出了Java17。但当我们翻看网络上面DDD相关的文章与书籍的时候,发现这套思想与战术相当活跃,被一些互联网大厂,保险公司和金融公司广泛使用。这个时代的技术人员是幸运的,2010年前的DDD学习者所经历的那段知识蛮荒何其悲哀。

  纵观网络上对DDD的评价,有嘲讽的、有鼓吹的、有茫然的,你能在他们的脸上发现世间百态。不过总结起来,大家一致的想法是:“真难”。其实也很正常,Evic Evans、Martin Fowler这帮人可是这个圈子的绝世高手,常年混迹在国外各类面向对象圈子。当您还觉得练武的最高境界是手中无剑心中有剑的时候,那帮祖师爷已经还始自创神功了。况且,早在DDD之前已经有一帮先驱设计出了各类分析与设计方法,与其说老艾创造了DDD,不如说其是对前人及个人经验的总结与梳理。此外,DDD、微服务这些理论的最初都是英文所写。圈外老外看着都蛋疼,何况非英文母语国家的人 ?

  DDD中的战略部分中,一开始就讲到了子域与限界上下文,给了读者一计重击。我说DDD是超前的,为什么呢?让我们的脚步回退到2010年之前,那是个没有k8s、Docker、Spring Cloud的时代。假如我们严格按书的理论,把一个大型的系统分离成了很多很多的小系统,比如100个。即便有个一流高手,对系统做了合理的拆分,谁敢去高落地?100个服务,即使是双实例服务数量也高达200,怎么部署?服务间的调用链路如何跟踪?服务如何管理?所以说,“看不懂,不理解”很正常。那东西本来也只能有选择的落地。2010年后各类云原生技术有了高速发展,此时才是DDD大展伸手的最好时机。

  再来谈一下微服务与DDD的关系。微服务是一套思想也是一种架构风格,Martin Fowler大概于2004年提出。现在其所以可以大行其道,是因为有一套完整的云原生技术做支撑。部署有容器,流程有DevOps和各类工具,开发技术有Spring Cloud。可是一套系统想要使用微服务架构,最起码得先把微服务拆出来,这个就是DDD要干得事情了。它有一套理论告诉你如何将系统划小,还有一套技术告诉你如何针对每一个划小后的系统进行设计。所以,两者之间是一对儿老铁。着重提一句,如果您的公司组织结构不适合微服务架构(比如部门10个人,8个当领导的;比如开发同时也是运维),整个单体或有限个小单体没毛病,DDD不一定要使用微服务架构。一流高手即使最初是以单体方式落地一个系统,也可以在后续实现系统的快速拆分,这叫“专业”。

  学习DDD之前,推荐几本老书看看。书多且厚,您怎么也得每天认真的看1个小时吧?花花世界诱惑忒大,努力让自己做沉浸式阅读。

  • Head First 设计模式:学习一些基础的面向对象概念和重要的设计模式,为实际落地作准备
  • UML和模式应用:学习如何建模
  • 企业应用架构模式:拓宽一下眼界
  • 实现领域驱动设计:很厚重的一本,相对老艾的更加务实,推荐重复阅读
  • 领域驱动设计:软件核心复杂性应对之道,DDD开山之作,挺玄幻的

开场讲完,DDD对人的要求贼高,怎样才能在DDD的路上走得更远,且听下回分解。最后,一句“天行健,君子以自强不息”与读者共勉。

热门相关:首席的独宠新娘   仗剑高歌   重生之至尊千金   最强装逼打脸系统   名门天后:重生国民千金