36

领域驱动战术设计进度说明

 5 years ago
source link: http://zhangyi.xyz/process-of-domain-driven-tactic-design/?amp%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

我在GitChat发布的《领域驱动战略设计》课程于2018年10月结束,原计划是在2018年底或2019年初再发布《领域驱动战术设计》课程,没想到一拖再拖,而我自己也终于体会到起点作者的那种催更压力。我本想揣着鸵鸟的心态躲在后面默默地写、慢慢地写,不给自己设定最终期限,没想到读者群里的众多读者已经开始发出了自己的呼声:

eMRbeeq.png!web

我想,我没法再藏起来假装自己不知道,只得站出来给大家汇报。

课程大纲

我计划的《领域驱动战术设计》课程共分为六部分内容,分别为:

  • 领域模型
  • 分析模型
  • 设计模型
  • 实现模型
  • 融合
  • 案例分析:EAS系统

第一部分:领域模型

领域驱动设计的核心是模型驱动设计,但Eric Evans并没有费太多笔墨来探讨“模型”。我认为讨论任何技术问题,都应该先明确技术概念的含义,在达成一致认识的前提下,才谈得上该如何设计与实现。

我发现许多人在争执领域驱动设计的问题时,甚至都没有分清楚什么是领域建模,什么是数据建模,二者的差异又是什么?因此,我希望在本部分对“模型”来一个彻底的讨论,阐释模型在软件设计中的角色和价值,并比较数据模型、服务模型和领域模型之间的区别。

对于领域驱动的分层架构,我在《领域驱动战略设计》课程中已有深入分析,但我发现很多读者依然会混淆各个层次中的模型,例如什么是DTO?什么是持久化对象?它们和领域对象之间的关系?这些问题真的是剪不断理还乱。所谓“正本清源”,要掌握领域驱动设计,这些概念是需要甄别清楚的。

本部分,我还比较了事务脚本、表模块和领域模型,并由此探讨了模型与编程范式之间的关系。

第二部分:分析模型

在第一部分,我将领域模型分为分析领域模型、设计领域模型和实现领域模型三种模型,故而接下来的三个部分我将开展对这三个模型的介绍。

分析模型是在分析阶段进行建模后的结果,由于领域驱动设计强调以领域为核心,因而由领域专家与开发团队达成一致的统一语言将在分析模型中扮演非常重要的角色。

软件分析是一种技能,但我们也可以借鉴一些方法,来帮助我们提高分析的能力。因此,在本部分我会利用分析模式、四色建模和事件风暴来帮助我们获得分析模型。若有可能,我还希望再加上一个ICONIX方法,虽然它已经垂垂老矣,但该方法蕴含的一些设计思想仍有值得借鉴之处。

第三部分:设计模型

这部分才真正进入领域驱动战术设计的内容,你会看到实体、值对象、领域服务、领域事件等耳熟能详的设计要素。即便如此,针对这些基本的设计要素,许多读者仍然存在对它们的理解差异,我希望能够说清楚这些设计要素,并结合案例来展现一个正确的领域模型会给我们带来什么样的价值。

聚合在领域驱动设计中极为关键,是Eric Evans提出的一个非比寻常的创见。然而,一直以来,我们却不知道该如何设计高质量的聚合,我希望我能尽量帮助读者理解聚合的意义,以及识别聚合的原则和方法。

在领域驱动设计中,许多人常常分不清楚领域服务和应用服务之间的差异,也没有能够理解资源库和DAO之间的区别,针对这些棘手问题,我会努力给出清楚的答案。

从本质上讲,Eric Evans的领域驱动设计其实就是对面向对象设计的运用。如何进行良好的面向对象设计呢?“职责”才是面向对象的核心,因此我将结合案例阐释我对职责驱动设计的理解,并给出可行的设计方法与过程。

DCI模式与职责协作有相似之处,它强调在不同场景(Context)中各个角色之间的协作。理解DCI,有助于我们理解什么是多态,什么是SPI。许多设计本质其实是愈辩愈清的。

第四部分:实现模型

实现模型基本可以认为是代码模型,我希望通过这部分内容回答常见的实现难题,包括:

  • 贫血模型与充血模型的问题
  • 领域模型与持久化
  • 通过事务保证不变量与一致性

在这部分内容中,我还将引入重构、测试驱动开发和整洁代码的知识,以求实现模型在代码层面能够清晰直观地体现统一语言。

第五部分 融合:战略设计与战术设计

领域驱动的战略设计与战术设计不是割裂的,在本部分,我将呼应战略设计的内容,将这二者结合起来。内容包括分层架构、REST服务、Dubbo服务与核心的领域模型以及CQRS模式。

第六部分 案例:EAS系统

仍然采用战略设计中的EAS系统作为案例,如此可以体现整个领域驱动设计的全貌。在战术设计课程中,我将结合战略设计得出的限界上下文,对EAS系统的核心领域进行分析建模,然后在分析模型的基础之上,通过引入领域驱动设计的设计要素和设计模式,获得设计模型,最终通过代码来实现。整个EAS系统是一个相对完整的代码库,届时会发布在github之上。

进度

我原计划战略设计课程能在九月份完工,随着战略设计课程的发布,我就可以提前着手撰写战术设计课程的内容。没想到我在编辑和修改战略设计课程的时候,并不满意之前已经写好的稿件,于是开始不停地重构乃至于重写,进度被拖慢后,到最后的案例部分,甚至变成了一边写作一边发布。简单来说,就是在发布课程的最后阶段,我手里已经没有存稿了。

因此,我真正开始撰写战术设计课程内容,已经是2018年的11月,进度比原计划足足晚了两个月。这期间,因为自己的懒惰,写作进度非常缓慢。此外,在闲暇之余我也需要抽出时间陪伴家人,自己负责的项目进度压力大,导致每天专心写作的时间越来越少,拖延症的威力也越来越大,眼看着进入2019年的三月了,进展依旧缓慢。目前的进度大致如下:

  • 第一部分:领域模型 完成情况:50%
  • 第二部分:分析模型 完成情况:80%
  • 第三部分:设计模型 完成情况:60%
  • 第四部分:实现模型 完成情况:0%
  • 第五部分:融合 完成情况:0%
  • 第六部分:案例分析 完成情况:30%

从进度情况看,一旦我完成前面三个部分,基本上就可以考虑课程的发布了,之后的内容可以写作与发布同步进行。根据我目前的写作速度,我的理想发布时间应该会在四月中旬或下旬。会不会太晚?没有办法!有多少项目是按时交付的?写作不是件简单的事情,高质量的写作就更不容易。我的写作我做主,大家慢慢等吧!我不为时间负责,我只为质量负责!

如此,算是广而告之!


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK