文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

领域建模的常见问题及解决方案

2024-11-29 21:21

关注

问题一

问题描述:业务专家与建模专家之间形成能力的“阻抗不匹配”。

就像对象和关系的“阻抗不匹配”一样,业务专家精通业务,却往往不具备建模能力,而建模专家又往往不熟悉业务(如我,只能泛泛地了解业务知识)。

这就是DDD为何强调领域专家与开发团队工作在一起的主要原因。

解决方案:除了让业务专家和建模专家共同工作,取长补短之外,还有一个办法,就是向企业的业务专家开展领域建模的培训,以提升他们的建模能力;同时,尽可能采用团队成员共同参与的协作化可视化建模,以促进有效沟通,快速反馈,有效形成业务专家与建模专家的合力。

图片

为何事件风暴得到大多数领域专家的认可,并成为一种主流的建模方法?其中一个原因就在于它通过可视化工作坊的形式,为业务专家和建模专家营造了良好的沟通氛围和高效的沟通机制。所谓的“糊墙”游戏,使得参与者可以释放自己,交头接耳,大声讨论,清晰地表达各自的想法。大家协同建模,通过即时贴展现业务流程与事件流,一旦将它们挂在墙上,就很容易发现大家对业务问题理解不一致的地方,通过发现差异统一认识,也起到了传播业务知识的目的。

可视化工作坊的形式可以有效杜绝“闭门造车”的专家建模,即便你不熟悉事件风暴,你也可以采用其他的头脑风暴形式。

问题二

问题描述:在开展领域建模时,缺乏一套行之有效的方法与过程,导致“拍脑袋”建模和随意建模成为常态,无法稳定地输出高质量的领域模型。

解决方案:通过引入DDD方法,建立适合团队的固化建模过程,是成功建模的必要条件。

下图是我总结的服务风暴12步骤,要求团队严格按照它规定的步骤逐步开展建模。

图片

遵循我总计的领域驱动设计统一过程,共分为三个阶段:

每个阶段都有4个步骤,并给出了每个步骤的执行过程与输出结果。前一个步骤的输出结果,又会成为后续步骤的重要输入。

例如,我规定了全局分析阶段的交付物包括业务流程图、业务服务图、业务服务规约和业务架构视图。

图片

图片

图片

图片

架构映射阶段的交付物包括系统上下文图、限界上下文组件图、API契约定义、服务调用时序图和应用架构视图。

图片

图片

图片

图片

图片

领域建模阶段的交付物包括限界上下文的代码模型、静态领域模型和动态领域模型。

图片

图片

图片

问题三

问题描述:面对业务复杂度高,规模庞大的问题空间,难以保证建模的质量,也无法有效控制复杂度。

解决方案:需要遵循“分而治之”的思想,在各个层次开展抽象与分解的工作。

DDD提出的子领域可以有效分解问题空间,限界上下文和聚合在不同层次上完成对解空间的分解,都是建模的重要支点。下图是我总结的DDD各层边界控制的内容。

图片

无论从问题空间到解空间,还是从战略设计推进到战术设计,领域驱动设计一直强调的核心思想,就是对边界的界定与控制。

控制了模型(战略层次和战术层次)的边界后,不仅因为缩小规模而降低了建模的复杂度,还能够在规定好各个单元之间的协作机制后,将它们分配给不同的领域特性团队,确定好职责边界,开展并行建模,如此也可以极大提升建模的效率。

问题四

问题描述:容易出现大而全的领域模型,看起来很美,一旦落地,会发现得到的领域模型存在很大的问题。

解决方案:遵循“迭代建模”的原则。迭代的过程是两个方向不断迭代的过程。

一个方向是在更高层次上追求“广度优先”,把建模工作尽可能覆盖得更广,形成统一而清晰的业务蓝图,包括主要的业务流程、划分子领域、确定子领域与业务服务之间的关系,进而确定限界上下文、定义限界上下文外部的接口,明确限界上下文之间的协作关系。

另一个方向是选择核心子领域追求“深度优先”,深入到这些核心子领域映射的限界上下文内部,编写业务服务规约,迭代地开展领域分析建模和领域设计建模,甚至尝试针对核心主流程对应的限界上下文开展实现建模,输出功能不完整,但具有可用特性的可运行代码。

融合广度优先与深度优先的迭代建模方式,和DDD结合起来,简单来说就是战略设计采用广度优先,战术设计采用深度优先。

这种迭代建模方式需遵循MVP(Minimal Viable Product,最小可用产品)思想。在确定了解空间的限界上下文,可以开展如下图所示的领域建模方式:

图片

遵循MVP思想开展的迭代建模具有两个优势:

我特别害怕企业搞轰轰烈烈的“建模运动”,从上到下打鸡血,定任务,高呼“奋战30天,多快好省地打造企业级领域模型”,然后,集中核心成员加班加点完成一个貌似完整详细、巨细无靡、规模庞大的超级领域模型,却没有产出哪怕一行可以工作的代码。在得到这么一个超级领域模型之后,企业又召集许多业务专家和建模专家对它进行几天封闭式的模型评审。这一做法虽然利用了团队的力量,做了充分的沟通和协作,但和“闭门造车”的专家建模一样,缺乏及时反馈与快速验证,得到的大而全的领域模型很有可能只是一个看起来很美的空中楼阁。

来源:逸言内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯