项目设计原则

单一设计原则

做过管理系统项目的同学肯定都接触过用户、机构、角色管理这些模块，实现方式都是基于RBAC模型（Role-Based Access Control，基于角色的访问控制，通过分配和取消角色来完成用户权限的授予和取消，使动作主体（用户）与资源的行为（权限）分离）

优点

▪ 类的复杂性降低 实现什么职责都有清晰明确的定义

▪ 可读性提高 复杂性降低 那当然可读性提高了

▪ 可维护性提高 可读性提高 那当然更容易维护了

▪ 变更引起的风险降低 变更是必不可少的 如果接口的单一职责做得好 一个接口修改只对相应的实现类有影响 对其他的接口无影响 这对系统的扩展性 维护性都有非常大的帮助。

高内聚低耦合原则

▪ 一个功能模块内功能要联系密切

▪ 把联系不密切的功能放在不同的功能模块内

▪ 尽量减少模块间的联系

高内聚低耦合是软件工程中的概念 是判断设计好坏的标准 主要是面向对象的设计 主要是看类的内聚性是否高 耦合度是否低

耦合性与内聚性是模块独立性的两个定性标准 将软件系统划分模块时 尽量做到高内聚低耦合 提高模块的独立性 为设计高质量的软件结构奠定基础 内聚是从功能角度来度量模块内的联系 一个好的内聚模块应当恰好做一件事 它描述的是模块内的功能联系 耦合是软件结构中各模块之间相互连接的一种度量 耦合强弱取决于模块间接口的复杂程度 进入或访问一个模块的点以及通过接口的数据

粒度把控原则

控制用例的总体数量：一般来说 一个相当复杂的系统的用例数量可能在30-50个之间 如果一个系统的用例数量大大超过了这一范围 那就该看看是不是陷入了功能分解的误区

高内聚、低耦合：用例是一种结构化写作需求的技术 用例是被从现实的场景中抽象出来的
如果这些场景有紧密的联系（高内聚）那用用例技术来组织它们则可以复用这些场景中的步骤描述 从而达到事倍功半的效果

写写看：很多时候在初步规划用例模型的阶段 有时很难判断一个用例的粒度是否合适 不要执迷于一次获得一个完美的用例模型和用例粒度 不妨先得出一个初稿 然后写写用例 看看是不是符合高内聚、低耦合的原则 实际上在写用例的过程中 用例模型往往是需要不断进行调整的

避免功能分解：功能分解是正确使用用例技术的最大敌人 很多用例粒度的讨论其实都是功能分解的思想在作怪

AKF原则