软件从建模开始

文章主旨：在软件开发中，通过建立合适的业务模型可以简化复杂业务、降低系统脆弱性，并提升开发效率与代码稳定性。

关键要点：

• 建模是简化现实世界复杂性的必需手段，软件开发中同样需要模型来传递业务知识。
• 若模型选择不当（如从界面操作出发），会导致需求描述繁琐、系统易变；找到合适模型（如日心说 vs 地心说）可使开发更简单。
• 案例说明：在培训系统中，增加“期班调查表”模型后，查询与提醒功能逻辑变得清晰简单。
• 检验模型好坏的方法：每个模型的每个操作只能有一个业务原因；若一个模型承担多重职责，易产生坏味道（如并发冲突问题）。
• 用户故事的“小”可定义为：最大用户故事不大于对一个模型的一个写入操作（增删改），避免涉及多个模型写入。

内容结构：

1. 模型在知识传播中的普遍性：人类通过简化模型描述世界，如牛顿运动定律在宏观世界的有效性。软件开发同样是知识传播活动，需借助模型将业务知识转化为代码。举例：汽车驾驶模拟软件需要加速踏板、方向盘等模型，避免不必要的精细度。
2. 不建模或浮于表面建模的弊端：从界面操作出发描述需求会导致系统脆弱易变，例如用“按向上箭头场景变大”代替车辆模型。好的模型能抓住业务本质，降低变更成本。
3. 选择合适模型的重要性：太阳系模拟中，地心说模型导致每颗行星单独编码，而日心说模型用统一代码加参数即可。当业务规则难以描述时，往往需要寻找更优模型。
4. 实际案例：培训系统的期班调查需求。最初因缺少模型导致验收测试复杂，引入“期班调查表”后，通过查询未填写结果的调查表即可实现提醒，逻辑简化。
5. 业务模型建立方法：成熟业务可从单据、物品、角色等发现模型（FDD、DDD、XP隐喻）；非成熟业务需先业务建模，纸上模拟后再开发。
6. 检验模型坏味道的标准：每个模型的每个操作只能有一个业务原因。举例：若将“期班调查表”和“期班调查结果”合并为一个模型，则修改表与填写结果会冲突，产生竞态条件；分开成两个模型可通过唯一索引避免并发问题。
7. 用户故事大小的定义：最大用户故事应不大于对一个模型的一个写入操作，避免涉及多个模型同时写入（级联操作除外）。

文章总结：本文强调建模是软件需求分析的核心，通过合理建模可显著降低复杂度、减少坏味道，并为用户故事大小提供可量化标准，建议开发者重视业务模型的设计。

DevOps帮助数字化转型的5种方式

了解更多

老邓聊开发

查看原文：软件从建模开始

文章来源：

老邓聊开发

扫码关注公众号