07 通过业务建模应用业务知识
你好，我是徐昊，今天我们来继续学习AI时代的软件工程。
从今天开始，我们进入到第二部分的学习：如何使用大语言模型（Large Langauge Model，LLM）辅助我们的软件研发和交付过程。在前面一节课里，我们已经从宏观层面上厘清了这个思路：将软件交付看作知识过程，识别其中的认知行为模式，并选择恰当的LLM交互模式，有目的性和针对性地提高整个知识过程的效率。
在这个过程中，我们将着重看待不同种类的知识是如何发挥作用的，以及如何将它们转化为LLM易于理解的结构。
那么今天我们先从业务模型开始，看一下业务模型是如何帮助我们理解业务的。
业务模型是如何发挥作用的
我们都知道，软件开发的核心难度在于处理隐藏在业务知识中的复杂度，模型就是对这种复杂度的简化与精炼。
我们通过模型捕捉领域或业务知识，使用模型构造更易维护的软件。模型就是精粹的知识。我们借助模型形成统一语言（Ubiquitous Language），达成对于问题或解决方案的理解。
我们通过建模获得模型，而建模是一个非常复杂的问题，有各种不同方法。我之前有一个专门的课程讲述这个问题，这里就不再赘述了。有需要了解这方面知识的同学，可以参看相应的课程。
我们目前关注的是，当得到了模型之后，怎么使用模型，帮助我们应用凝结在模型中的业务知识。这个过程，我称之为模型展开。所谓模型展开，就是在给定的业务上下文中，将模型中的概念实例化，通过实例化的模型，解释业务上发生了什么。下面看一个例子。
假设我们现在为某学校研发学籍管理系统，那么它的模型可能是这样的：
这是一个简化的领域模型，描述了学籍管理系统的核心知识：
- 学院提供不同的教学计划，比如信息学院可能提供计算机科学与技术学士学位教学计划，或是计算机科学与技术硕士学位教学计划；
- 不同教学计划有对应的教学大纲。教学大纲中则规定了学生需要学习的课程。比如，计算机科学与技术学士学位教学计划的教学大纲中，规定了学生的必修课离散数学；
- 学院为学生发放录取通知，通知学生被哪个教学计划录取，比如张三录取为学士学位学生；
- 学生根据录取通知将学籍注册到指定的教学计划，比如，张三根据录取通知注册为2023年入学的计算机科学与技术学士学位教学计划学生；
- 学士在学籍有效期内，需要根据教学大纲选课。比如，张三在攻取学士学位的时候，学习了离散数学。
接下来，我们就可以在具体的业务场景或是功能需求中，通过模型来应用这些知识了。让我们看几个例子。这里所有的需求我都会以用户故事（User Story）的形式给出。
以学生入学为例，按照我们要求学生需要拿到录取通知后，方能入学，那么用户故事可以写成：
作为学校的教职员工（As a faculty），
我希望学生可以根据录取通知书将学籍注册到教学计划上（I want the student to be able to enroll in an academic program with given offer），
从而我可以跟踪他们的获取学位的进度（So that I can track their progress）
第一个验收条件是可以成功注册的情况。我们使用如果/当/那么（Given/When/Then）的形式描述验收条件：
如果获取了录取通知书的学生没有注册学籍时（Given student with offer hasn’t enrolled any program），
当这个学生注册时（When the student enroll），
那么这个学生将能成功注册学籍到录取通知书指定的教学计划中（Then the student will successfully enroll the program specified in the offer）
那么我们可以在这个验收条件的上下文中将模型展开。
如上图所示，我们将模型在这个验收条件的上下文中做了实例化。对应验收条件中，Given的描述是“获取了录取通知的学生没有注册学籍时”，这表示存在一个Offer对象实例，而没有Program Enrollment的实例；而Then的描述“这个学生将能成功注册学籍”，则表示我们可以生成Program Enrollment的实例，并将这个实例与Offer中的教学计划关联。
另一个验收条件是，如果没有拿到offer则不能注册。我们仍然使用如果/当/那么（Given/When/Then）的形式描述验收条件：
如果学生没有获取录取通知书（Given student doesn’t have an offer），
当他尝试注册时（When the student try to enroll），
那么这个学生将无法注册学籍（Then the student can’t enroll any program）
同样我们可以根据这个验收条件的上下文将模型展开。
展开之后，这个模型就简单明了了，Given的描述是“学生没有获取录取通知”，那么也就是不存在Offer对象实例；而Then的描述“这个学生将无法注册学籍”，则表示我们不会生成Program Enrollment的实例。
在这两个例子中，我们关注的是学生学籍注册这个行为或功能。但是我们并没有直接描述它，而是从状态/数据改变的角度，描绘了业务行为发生前后模型实例的变化。这样，我们就使用了静态的模型解释了动态的行为或功能。
在使用模型解释业务的时候，是否会出现多种不同的解决方案呢？在解释的过程中，我们只使用了模型中的概念和关系，因而对于某一个场景，实际只存在唯一符合业务场景的描述。这是因为在模型中还隐藏着时间维度。
模型中的时间维度
让我们再仔细看一下前面的模型，就会发现其中实际存在着时间顺序。首先是学院。学院是早于教学计划的。没有对应的学院，也就不存在各种学位的教学计划。然后教学计划是早于录取通知书的，如果没有教学计划也不可能发放相应的录取通知书；最后是录取通知书是早于学籍，因为学生是根据录取通知书注册的，如果没有录取通知书，学籍注册也就无法完成。
模型中的时间维度，与模型中关系的性质有关。这就是为什么无论在面向对象设计还是领域驱动设计，抑或是其他什么设计方法中，对于聚合、组合、引用等概念都要详加区分。因为它们表示了不同的时间关系。
如上图所示，我们在模型中标注了引用与聚合关系。不难看出：
- 聚合根要先于被聚合的对象存在。比如，学院-教学计划。
- 被引用的对象要先于引用对象存在。比如，录取通知-教学计划。
那么我们在展开模型的时候，也可以把时间维度单独标示出来，这样更利于我们处理数据持久化时，理解不同对象的生命周期。比如，在针对这个验收条件：
如果获取了录取通知书的学生没有注册学籍时（Given student with offer hasn’t enrolled any program），
当这个学生注册时（When the student enroll），
那么这个学生将能成功注册学籍到录取通知书指定的教学计划中（Then the student will successfully enroll the program specified in the offer）
进行模型展开的时候，我们可以加入时间的维度：
图中最下方的横轴，表示时间轴，也就是时间的顺序。图形在时间轴上的位置，表示了它们产生的时间的顺序，也就是学院早于教学计划，早于学生，早于录取通知书，早于学籍。当然，严格来说，学生与学院哪个是最先产生的并不重要。它们可能是从其他数据源导入的，是时间不敏感的信息，类似的还有课程，也是一样的情况。
时间轴上有一个关键节点，就是我们当前的业务场景注册。在注册之后，我们产生了新的实体学籍，同时产生了新的关联关系，也就是图中用虚线表示的张三-张三的学籍，还有教学计划-张三的学籍。
类似的，对于第二个验收条件“如果没有拿到offer则不能注册”。
如果学生没有获取录取通知书（Given student doesn’t have an offer），
当他尝试注册时（When the student try to enroll），
那么这个学生将无法注册学籍（Then the student can’t enroll any program）
包含时间线的模型展开后是这样的。
可以看到，我们既没有生成新的实体，也没有建立新的关联。
在理解了模型中的时间维度之后，通过模型展开，在产生了什么样的实体与关联，这些实体和关联产生的顺序是怎么样的这两点上，我们就能容易地达成共识。也就是使用了模型帮助我们理解了业务。
小结
今天我们讲解了模型展开，以及如何利用模型展开去理解业务。通常我们会更关注于建模，也就是模型的提取过程，而往往忽略了模型提取后如何有效应用模型。
行业里有大量关于建模的讨论，但是涉及真正使用模型去形成统一语言，就很少有人提及了。这一方面是因为利用模型形成的统一语言，是一种不可言说知识。另一方面也是因为，我们往往更关注知识的产生，而忽略知识的消费。
从知识工程的角度来看，在我们应用模型来理解业务的过程中，我们处在什么样的认知行为模式呢？很显然，我们是处在庞杂的认知行为模式上的。通过分析，我们将模型中定义的模式（对象类型与关系种类）应用到当前的上下文中。
那么我们使用LLM帮助提效的思路是什么呢？思路就是构建思维链（Chain of Thought），也就是通过思维链辅助LLM理解模型应该如何展开，这就是我们下节课要讲的内容。
思考题
模型展开这部分推荐你自己练习一下，才能充分掌握。请你结合你的工作实践，思考另外几个业务场景，并做模型展开。
欢迎在留言区分享你的想法，我会让编辑置顶一些优质回答供大家学习讨论。
- 临风 👍（8） 💬（0）
一开始看今天的模型，感觉有点懵，因为我没有经历老师的思维过程，不知道模型是怎么得出的。然后在老师的《如何落地业务建模》的第三讲，我看到了这样一句话，“我们始终要记住，模型是对问题的抽象，没有对错，只有角度不同“。 于是我就大胆按我自己的想法构建模型，如果让我设计一个学籍管理系统，我可能第一个想到的对象就是学籍。那么谁拥有学籍，一定是某个学生；学生是如何拥有学籍的，一定是学生进行了报道，注册了学籍；为什么他能报道，一定是学院给了他offer；那为什么学院会给他offer，一定是他报名了这个学院的专业并且达到了分数（这里可能会涉及到报名录取的一个外部依赖API）。 学生拥有学籍后要干嘛，上课呗，然后才能毕业，于是我们又得到了课程；那课程是怎么来的呢，是教学大纲规定的，然后教学大纲又是教训计划所指导编写的，我们又可以得到教学计划和教学大纲；最后，学生要怎么才能上课呢，就又涉及到选课。可能我还会设计一个学分的对象，这样就能知道这个学生是否满足毕业的学分要求。 可能最后画出图来，和老师的也差不多吧，最重要的是经过这个思路的整理，再看老师的模型图就清楚多了。难怪在过去的时候，构建领域模型是十分困难的一件事，下节课就要讲CoT，期待会有新的思考和启发。
2024-03-22 - aoe 👍（2） 💬（1）
模型展开太厉害了，还带时间属性 又学会了一个新技能，感谢老师
2024-03-25 - 范飞扬 👍（1） 💬（3）
原文：聚合根要先于被聚合的对象存在。比如，学院 - 教学计划。 --- 那既然是聚合，模型图里应该用空心菱形而不是实心吧？钟敬老师在《ddd》课是这样说的
2024-04-04 - 大卫 👍（2） 💬（2）
模型的展开过程就是形成统一语言的过程，也就是不可言知识的传递过程！此过程会涉及功能需求的描述和功能模块的划分甚至更细致的TODOs！ 正如《落地建模》中所讲的模型/统一语言/业务需求三者关系。模型在时间维度的展开就是用UL来描述需求，如果有不能描述的需求就要再次提取知识演化模型，形成新的UL来描述需求也就是用户故事的产生！ 如果CoT能高效生成正确的用户故事，那么CoT模板就提高不可言知识的传递效率！
2024-03-22 - 范飞扬 👍（1） 💬（0）
“录取通知书早于学籍” 这个好像没有在模型图里体现呀？是不是应该在 录取通知书 和 学籍 之间加一个关联关系才能体现呀？
2024-12-17 - 赫伯伯 👍（1） 💬（1）
上完课，感觉似乎用另一种方式，把活动图，序列图和状态机图干的事儿又搞了一遍。是为了让大语言模型能更好的吸收知识吗？
2024-03-22 - 6点无痛早起学习的和尚 👍（0） 💬（0）
2024年05月03日09:48:22 看到这节课的内容，画的图，在思考公司里技术方案按照这么标准的画图，又有多少呢？我在某个大厂的某个金融业务下就没有见到，能把 uml 的关系图画如此标准
2024-05-03 - 术子米德 👍（0） 💬（0）
🤔☕️🤔☕️🤔 【R】模型，用统一语言（Uniquitous Language）描述，将高复杂度的业务知识，进行简化与精炼，用于构造更容易维护的软件。 模型之前，可用DDD的方法，之前，模型之后，开发人员理解模型、以不可言说知识去实现、并完成交付；如今，模型之后，如何跟LLM一起、提取出可复用的、不可言说知识为提示词，来达到知识复用、进而提高知识传递效率，即所谓【LLM based BizModel Applies，基于大模型的业务模型应用】。 【.I.】根据业务建模型，这是架构师的活，让业务域的所需以问题的样子，被技术域的所能以求解的样子，合起来变成题目和答案的业务模型样子，开发人员拿着模型去实现。开发人员之所以能理解模型、能实现模型，既有显性知识，还有更多不可言说知识。这就是收购时，为啥不能只买几个架构师，得把整个团队成员都买去的缘故。 如果，现在切换到基于大模型的开发范式，架构师的活，还得继续干，他要交付模型，开发人员的活，每干一轮，就会被LLM提取些不可言说知识出来。 【Q】LLM会像吸血鬼一样，持续吸出开发人员的不可言说知识吗？ — by 术子米德@2024年3月24日
2024-03-24 - 一只豆 👍（0） 💬（0）
这节课的内容不算太难理解，不过因为是新一章的开篇，而且是为了下一讲铺垫，我在使劲试着找背后的脉络感来调整注意力的姿势。 我理解，建模是一件昂贵的事情，所以要充分发挥（精炼业务知识后才得到的）模型的作用才没有白白建模。所以，模型像是一个以关系数据库状态存在的，很干很干的信息内核，未来会在这个内核外面漂浮很多信息场景，即被用户以不同业务场景的视图来访问。要想开发好这些信息场景，就需要开发人员深度理解这些场景。但一方面很干很干的信息内核对开发人员不友好，再者团队内部的业务认知也非常不均衡，所以存在很多误解和反复沟通的日常痛苦剧情。 于是我们可以利用LLM 丰富的常识和知识储备，让 LLM基于信息内核（一种强编码的上下文描述），并且使用 CoT 的方式 （因为这是不可言说知识的提取）来把这个干货变湿，让人类开发者用自然语言就get 到很多具体的业务场景到底会怎么运转。这样就实现了 第六课中提到的， 在庞杂认知模式下，通过复用思维链实现团队成员之间不可言说知识的高效传递。这样既解决了团队中认知分布不均衡的问题，也充分发挥了（辛辛苦苦才建立）业务模型的作用。 这就是利用 LLM 进行业务模型（给人类）展开的价值。
2024-03-22