Day 26: 策略和层级、业务规则 (待改进中... )

「软件系统是策略(Policy)的陈述。电脑程序是将输入转换为输出的『策略的详细陈述』」

「会因着相同的原因在相同时间变化的策略，处在同一层级，并且会隶属於同一个元件。架构的艺术通常涉及到将元件重组成一个有向无环图(DAG)」

取自: Clean Architecture (p.153 & p.154)

CH19: 策略和层级

• 好的架构...

层级 (Level)

• 「层级」的严格定义是 「与输入及输出的距离」
  • 离系统的输入和输出越远，策略的层级就越高
  • 管理输入和输出的策略，是系统中最低层级的策略

经典案例：加密程序

UML...

// code...

CH20: 业务规则 (Business Rules)

「业务规则有着几种不同的类型，严格地说，它是赚取或节省商业资金的规则或程序。非常严格地说，不论是否在电脑上，即便是手动执行这些规则，它们都可以赚取或节省商业资金」

「业务规则应该保持质朴的状态，不受 UI 或 DB 等基础问题所影响。它们很少会关注谁 Plugin 进来。业务规则应该是系统中最独立、最可复用的程序码」

取自: Clean Architecture (p.157 & p.161)

• 关键业务规则
• 关键业务资料

P.S. 作者关於 Business Rules 的定义马上让我思考到非营利组织 (例如教育平台)，它们的核心业务规则又是什麽呢? 我想，也许就是一个领域中最核心的 Know-how 吧。又或许可以作者的另一句话来概括：

「业务规则是软件系统存在的原因，它们是核心功能。它们是程序中的宝石」

实体 (Entity)

(TODO: 换一张图，或自制)

...

• 补充: 有关 Entity 实作与细节，笔者还是想再推一次这系列铁人文 － DDD 战术设计： Entity 概念与实作

使用案例 (Use Cases)

(TODO: 自己制图..., 把两张合并...)

请求与回应模型 (Request and Response Models)

Reference

A UML class model defining business domain
软件需求分析与塑模
Use Cases and Business Rules: Can They Work Together?