PM Suite领域建模实录：对话式澄清方法

领域建模在实践中往往不是架构师闭门画图，而是和领域专家一问一答、逐步修正的对话过程——书中用PM Suite项目管理系统的建模实录完整演示了这种方法论。建模从”项目被分解成许多任务，分配下去”这句朴素描述开始，架构师先画出”任务分配给项目成员”的初步关系，随即追问细节：”每个任务只能分配给唯一的人，而一个人可以负责多个任务”——这类追问把模糊的业务描述转化成了精确的基数关系。更关键的一幕是架构师主动假设”一个项目分解为多个任务，一个任务只能对应某一个项目”（默认一对多），领域专家立刻纠正：”我们必须支持多项目管理，多个项目可能共享某个子任务”（比如身份验证、消息机制这类领域无关的通用模块）——这次修正说明”不要想当然”：架构师习惯性地用最常见的关系模式（一对多）去套业务现实，但真实业务往往比默认假设更复杂，唯有通过具体追问和举例才能暴露这种偏差。类似的澄清过程贯穿整个建模实录：任务之间存在前后依赖关系（某任务结束后另一任务才能开始）、资源（人/设备/材料）在逻辑上被项目占用、但具体使用要分配到任务并明确使用期限——每一次领域专家给出新的业务事实，架构师就把它转化成模型上的一条新关系，模型逐步从零散变得系统。第二天的状态图建模同样遵循这个模式：先画出项目的未启动/进行中/已完成/已取消四种状态，再追问”状态因何而发生变化”，再追问”每个状态变化会对项目团队产生什么影响”（比如项目完成和取消这类重大事件应该通知所有人，这条线索还牵出了公告板功能），最后利用模型中已有的时间点、工作量等概念，进一步细化出”进行”状态下的多个子状态。这套方法论的核心价值在于：领域建模不是一次性的设计动作，而是一套可以反复执行的”提问-建模-验证”循环，每一轮追问都在系统性地暴露此前被忽略或想当然的业务细节。