05｜领域建模实践（上）：怎样既准确又深刻地理解业务知识？

为什么领域建模要由业务人员和技术人员一起协作完成呢？ 1、知识传递： 技术同学说：我没太懂你到底想要个啥玩意儿 产品同学说：好，让我跟你再细说说 2、知识提炼： 技术同学说：你讲的我大概都明白了，但是就感觉有些凌乱，东扯一下，西扯一下，还是有点迷糊 产品同学说：好，那我们再来梳理一下，有些点确实可以归归类啥的，可能更方便理解 3、可视化： 技术同学：嗯，你的需求我基本是了解了，要不我把我的理解画出来，跟你确认一下？ 产品同学：好主意，那咱们一起来搞吧。 4、认知对齐： 技术同学：你看我画的这个，是那个意思哈，确定哈。 还有这个这个，是那个那个意思哈。 产品同学：对的对的，这个是对的。 不过，那个可能稍微再调整一下更符合实情业务情况。 5、统一语言： 技术同学：看来，咱们画这一波图，已经把需求的要点都囊括了哈。只是有些概念我感觉还是有点模棱两可，要不咱们再对一下，把这些概念的叫法给定死咯，这样我写代码的时候，也方便取名字。 产品同学：要得要得，我们再拉一个表吧，把所有的业务概念再罗列一遍，包括中文表达和对应的英文表达都敲定一下，以后咱们就以这个术语表为准来沟通。

这一课主要讲了模型及各自之间的关系 问题： 1. 业务和技术需要当前的模型结构是否适合未来， 对于电商的订单业务，刚开始时，我们是一个订单只做一个配货单，增加了下订单时要按仓库拆单，复杂度有点麻烦；为了保证前端用户下单的TPS，我们做了妥协，使用一个订单多个配货单处理，不影响前端效率，整体的方案如下图： https://www.processon.com/view/link/639a6faa1e085317e09dde02

1.两个角色在一起协作产出，是因为两个角色共同参与是必要条件（不然，单干效率最高）。为什么会是必要条件，因为我们假定业务知识只在业务人员脑子里，领域建模知识只在技术人员脑子里，我们要得出某块领域知识，用领域建模做的模型图就必须要整合这两块知识。两者谁更核心些，业务知识更核心些，毕竟建模这个事有各种方式，只要能高效传递知识都是好方式。 2.租户的概念很特别，是否放到领域建模需要斟酌。毕竟租户来源于saas，saas来源于客户对产品的使用方式。但不是所有的软件都需要产品化（我就搞个功能集的小软件，不做限定），不是所有产品化都采用saas（也肯能是专项交付）。 3.多对多都可以拆成两个1对多，而且最好拆掉，拆时时常能发现一些隐式概念。 以上边为例，“员工”-**-“岗位” 中间可以加个 “编制”，“员工”-1*-“编制”-*1-“岗位”。 "编织"可以挂组织，可以挂项目，取决于交付模式。 4.注释和约束还是看情况加吧，抽象模型目的是聚焦核心方便沟通，铺得越详细也就越失焦。把注释和约束交给故事卡背景/AC或则PRD，也是一种方式。（为什么有这个想法， 如果我抽象的模型需要一直改，哪很可能是抽象得并不好《还是太具象了》，比如文中的“开发中心”“直属部门”。uml图也是这个思路，加注释和约束后，要改的机会会显著增加）

1. 实际上DDD针对的复杂软件是个铁匠和花匠一起参谋做除草机的事情，业务人员懂它要干嘛，但是不懂如何做，铁匠能打造工具，但不知道工具如何被使用更好。单铁匠只能做出他学过的工具，比如他学过如何制造锄头，单花匠只能吐槽手里的锄头不好用。所以，从另一方面，如果这种软件你学过怎么做（你知道抄谁并且各种分析都到位了）就不要花匠（业务人员了）可能那个花匠还没你懂，不过能告诉我们开发人员抄啥的好日子好像越来越少了。

这个模型有点像《分析模式》第一节里面的模型。我比较好奇的是我们怎样去发现需要抽象的地方，就像例子里，为什么我们需要考虑组织层级变化这个点?其实也可以有其他的点，比如以后我希望企业和租户是多对一的关系，就关于抽象组织层级这个好像也没有从需求里能看到蛛丝马迹，我们应该怎么训练这种能力呢？

正好同时在复习八叉老师的另一门课，里面提到的用知识消化（Knowledge Crunching），“双关联一循环”，来提炼领域模型。 让业务人员和技术人员一起，建立统一语言（Unified Language），建立双关联，也可以加速完成循环。

你好，企业是非常特殊的组织，企业最好作为独立的实体，即使合并也应该和租户合并。否则按企业查询用户，或按用户确定企业都很麻烦。

领域建模由业务人员和技术人员共同完成，是因为技术人员开发的软件，是技术人员从业务人员获得的知识在大脑中的反映，因此技术人员必须把业务人员脑子里的知识可视化出来，才能开发出满足需求的软件。 实际项目中，往往是一上来就开始建表，然后围绕表就各种CRUD，这样开发出来的面条式代码，往往没有表达出目标问题背后那些不变的本质的东西，因此需求越复杂就越到后面越难以维护，写成了一坨巨大的屎山，程序员每天在屎山里搬屎

业务最终要落地到技术实现上，业务人员可能会把所有的业务场景都罗列出来，但不能从代码实现层面对相似业务的抽象；而技术人员需要把业务需求转成实实在在的代码，但只关注编程语言等的特性，不能整体把握业务的整体。通过业务人员和技术人员的共同头脑风暴，完成业务的抽象，提高技术人员对业务需求的整体认知，才能使用合适的语言特性实现业务的真实功能。这是一个打破业务与技术之间墙的非常高效的方法。能把这两者之间融合于一身的人，才能称为系统级架构师，但能做到的人少之又少。太好的内容，很厉害的老师。谢谢

为啥感觉建模后，好复杂 😂