07|统一语言可以是领域模型本身吗?
徐昊
该思维导图由 AI 生成,仅供参考
你好,我是徐昊。今天我们来聊聊如何把领域模型作为统一语言。
在第二讲,我们谈论到为什么统一语言是必要的:一是因为业务维度在领域模型中被隐藏了;二是我们需要一个缓冲,去发现模型中不存在的概念。不过这里有一个隐藏的前提假设:最终建模结果将是原味面向对象范型的模型。
而我们在介绍上下文对象的第五讲里,已经见到一种不同于原味面向对象模型范型的思路:DCI 范型。围绕角色与上下文对业务进行分解,而不仅仅是实体与关系。那么我们是不是可以通过不同的建模范型,将领域模型本身当作统一语言呢?
答案是肯定的,而且其中最关键的就是如何将隐藏在模型中的业务维度展开。不同的建模范式,展开业务维度的方式与逻辑也不尽相同。我们首先需要更仔细地理解一下业务维度是如何被隐藏在模型中的,然后再看看不同的建模方法将会如何展开业务维度。
业务是模型的隐藏维度
我们仍然以你已经很熟悉的极客时间专栏领域模型为例,看看在订阅这个上下文中(模型如下图所示),原味对象范型的模型是如何将业务维度隐藏的:
作为技术人员,我们可以很容易地从数据角度理解业务行为:当用户订阅了一个专栏之后,就会产生一个新的 Subscription 对象,它会记录用户具体订阅了哪个专栏。而我们通过对 Subscription 对象的检视,就能知道用户一共订阅了多少个专栏。下图展示的是我们将模型实例化后的结果:
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
领域模型作为统一语言的重要性是本文的核心议题。作者强调了业务友好与可读的模型可以作为统一语言使用,而将模型变得业务友好与可读的方法主要有催化剂建模法及其变体和事件建模法。催化剂方法通过共享词汇表将交互显式地建模到对象模型中,展开隐藏在模型中的业务维度。而角色-目标-实体法则通过一个额外的表格将领域模型中的业务维度展开,提供了一种共创统一语言的流程。这两种方法都有效地解决了业务维度展开的问题,将领域模型变成统一语言。下一节课将介绍另一种不同的业务维度展开的方法:事件建模法。欢迎读者在留言区分享对催化剂方法和角色-目标-实体法的不足和改进方法的思考和想法。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《如何落地业务建模》,新⼈⾸单¥68
《如何落地业务建模》,新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(16)
- 最新
- 精选
- Jxin置顶体会 1.感觉本节提到的两种建模方法都属于服务视角的建模方式。同时包含了服务行为模型和服务资源模型,以服务行为模型对外与业务达成协议,以服务资源模型对内做软件实现。 课后题 1.目标直接关联实体感觉比较僵硬。大象uml的作者推崇依赖分析模型作为业务方与代码实现的桥梁。对应到文中,目标相当于用户用例,而实体已经跨过分析模型直接到实现了。这样关联性是强了,但牵一发动全身,耦合也很高,有个相对抽象的分析模型架中间能保留一定灵活性。 2.缺少事件流描述行为的流转。缺少规则描述前后条件。
作者回复: nice
2021-07-09225 - 冯催化剂方法和角色 - 目标 - 实体法,只得到了静态模型,没有业务流程。比如专栏可以通过”订阅“得到,那”订阅“的业务流程是什么样的模型里面没提到。基于以上,我的改进是为每个交互添加流程描述
作者回复: nice
2021-07-0910 - OWL课后题 角色 - 目标 - 实体法,和产品经理整理的用户故事及其相似。其缺点也很明显,缺少业务流转和完整性的显式化表达。可借鉴产品经理使用的用户故事地图,通过关键事件流进行建模。而对于简单的业务,特别是单体架构,使用Eric DDD中的Serivce进行封装建模。
作者回复: 下一课就讲这个
2021-08-084 - Oops!催化剂法有点像将用例向后展开出模型的意味,角色目标实体法可操作更强,通过表格的形式梳理业务流程和关联的实体。不过,实际业务中有很多异步业务流程,如何在模型中描述这些异步流程呢?
作者回复: 看事件法
2021-07-083 - 王博业务在领域模型中的展开,不可以借助时序图吗?
作者回复: 不行 时序是对象时序 并不是业务流程
2021-07-1232 - Geek_0e3b40既然想用领域模型作为统一语言这么麻烦,为什么不直接构造额外的统一语言,用领域模型作为统一语言有什么优势吗?
作者回复: 统一语言要形成共识 还要与模型关联。也不简单
2021-08-15 - 赵晏龙我发现很多方法/模式其实都是同一件事情的不同侧面和表述方式。 比如我认为文章中提到的【催化剂法】【角色目标实体法】,在软件实现阶段的一种具体实现方式是【行为驱动开发】。这些东西只是在不同的时代、时间点、场景下,有一些修正性的不同。整体的指导思维是基本一致的。 我使用BDD时间比较长,所以根据我的经验:纯粹【催化剂/角色目标实体法】能很好的解释单个操作/目标将会发生的事情,但是知识会非常的碎片化。如果不加以整理和讨论,用户将无法对整体业务流程有一个很好的理解。 感谢老师帮我梳理知识,继续认真学习!2021-07-088
- 常文龙角色-目标-实体的不足:本质上是一颗树,因此对于位于“叶子节点”的实体,缺乏了“对象间关系”这一层信息。而催化剂方法的对象关系描述的很清楚,是一张网。缺乏的是“交互”没有“软件组件”的对应。 除非,我们最终的模型产物=表格+对象关系图,否则这两种方法都只看到不同的侧面,都有缺失。2022-02-1913
- Marshall催化剂法最左边的用户,和模型语言中的用户概念上应该是一个。但左边更像是用例图,会有一点混乱的感觉。角色目标实体法则感觉太独立,缺乏一个比较直观的全局视角。2021-08-251
- 6点无痛早起学习的和尚怎么感觉“角色 - 目标 - 实体法”的建模过程有点类似“事件风暴”啊?不知道理解正确吗?2024-01-02归属地:北京
收起评论