模块的设计

模块的设计

• 包的划分应该按照业务来划分，而不是职责
• 职责越具体的类／模块，应该放在越具体的包内部
• 严格控制类的可见性，可见性越小越好
• 一个模块应该暴漏一个接口，这个接口作为与其它模块交互的唯一通道 同时也是模块边界的划定
• 模块的划分是多个层次的
• 模块内部通信，依赖是自由的；模块间的通信／依赖要慎重
• 模块间通信不应该使用Event
• 一个类的职责越少越好，越具体越好
• 业务模块的代码尽量不要追求通用性
• 业务的特点是发散式变化的
• 职责的横向扩展（追求通用）带来复杂性，增加维护难度的同时不能很好的应对／隔离变化
• 通过职责单一的模块的组合能减少复杂性和更好的应对／隔离变化
• 复杂的设计是存在很大代价的（可理解性，长期的维护性）
• 简单的设计应对复杂最好的方案
• 针对具体业务可以存在很多具体的假设（例如单线程访问，数据量不会超过某一个址），合理使用这些假设，可以极大的简化设计，降低复杂度
  1. 越具体越简单，因为有更多的假设可以依赖，可以大大缩减问题领域
  2. 模块应该专注于要解决的问题，尽量避免职责扩展，避免非核心问题带来的复杂度（8/2原则）
• 应该防止代码的设计超出设计使用范围的情况（针对上一点）
• 足够独立的模块的设计是自由的（重要模块最好能够进行设计评审）
• 随着业务的发展，模块／项目的整体设计都是再不断变化／进化的

---

基础模块 和 业务模块

通用

• 清晰的职责和边界
• 提供适度的扩展性（不要太多，不要太少，大部分情况下，只实现要求的指责，就足够好了）
• 认识清楚要解决的问题
• 认识问题是一个渐进的过程
• 专注于解决核心问题，抵制添加更多功能的诱惑
• 做更多的事情=更多的代码=更多的bug=更大的维护负担=将来更沉重的历史负担
• 简单一致的东西是最好理解的，适合概念迁移的
• 模块结构／架构的设计是跟随业务场景演进的，没有完成之日
• 大部分情况下，存在满足需求的自然的设计／结构
• 不用一开始就有特别详细的设计，对问题的认识是逐渐深入的，结构设计也是，这意味着追求动态最优，意味着变化的设计，意味着随时的重构
• 设计出来的东西一定有人以意想不到的方式使用，一开始就要限定职责
• 复杂意味着更快的变质，简单意味着更长的保鲜时间，更稳定的结构
• 复杂有时候是不可避免的
• 事物存在本质复杂度和偶然复杂度，把握问题的关键是识别和区分这两种复杂度

业务模块

• 业务模块设计没有定法，根据业务进行设计，演化
• 业务往往是发散式变化的
• 业务模块的首要设计要素是清晰的对应需求
• 业务模块不存在客观的最佳实践，适应的就可以了
• 业务的快速，发散变化意味着追求完美是没有长久意义的
• 业务的发散式变化意味着职能的扩展，职责太多的代码抽象不是好的抽象
• 新的业务需求开始的地方，就是重新思考设计的地方
• 不要假想可能存在的业务需求，将注意点集中在现有的业务，因为业务需求往往是发散的，满足假想的需求没有意义，而且带来额外的复杂度