分解系统
系统分解 是将整体代码库分解为单个组件和依赖项的过程。 此转换可减少系统的大小和复杂性，从而更高效地生成和管理维护。
在分解系统之前，需要更好地了解代码和解决方案，以确定哪些组件可以独立分离和管理。
分解的目标
主要目标是通过以下方式减少基本代码和系统的大小：
- 删除特定组件： 从解决方案中提取可重用组件。
- 集中代码： 将重复代码或共享代码合并到单个组件中。
- 独立维护： 允许单独维护和版本控制组件。
- 提高效率： 通过使用较小的代码库，加快生成速度。
分解过程
标识用于提取的组件
可以通过识别解决方案的特定组件来实现分解，具体组件可以是：
- 集中： 维护在单一地点。
- 重用： 由多个项目或团队使用。
- 独立维护： 按自己的计划进行版本控制并发布。
外部化组件
你将从解决方案中删除这些组件并将其外部化。 此过程涉及：
- 创建单独的项目： 将代码移动到新的解决方案工件。
- 发布包： 从提取的组件创建包。
- 引入依赖项： 更新使用代码以引用外部组件。
重要注意事项： 你以牺牲引入对其他组件的 依赖项 为代价外部化组件。 必须仔细管理这种权衡。
重构调用代码
查找和外部化组件的过程实际上正在创建 依赖项。 这可能需要重构：
代码组织更改：
- 创建新的解决方案工件：用于提取组件的新项目或存储库。
- 更新项目引用： 从项目引用更改为包引用。
- 重新组织文件夹结构： 与新的组件边界对齐。
代码更改：
- 更新 import 语句： 从其新位置引用组件。
- 处理中断性变更： 调整代码以兼容组件化接口。
- 删除重复代码： 将复制的代码替换为组件引用。
应用设计模式
可能需要引入 代码设计模式 来隔离并正确包含组件化代码。
分解的常见模式：
- 按接口抽象： 定义组件之间的明确协定以减少耦合。
- 依赖项注入： 允许在运行时提供依赖项，而不是硬编码。
- 控制反转： 让框架管理组件依赖项和生命周期。
- 外观模式： 为复杂的子系统提供简化的接口。
- 适配器模式： 允许不兼容的接口协同工作。
这些模式的优点：
- 测试： 可以使用模拟依赖项隔离测试组件。
- 灵活性： 可以在不更改使用代码的情况下交换实现。
- 可维护性： 清除边界使代码更易于理解和修改。
替代方法：利用现有组件
分解还可能意味着将可重用代码 的实现替换为 可用的 开放源代码 或 商业组件。
何时替换或提取：
- 替换为现有替代方案： 当存在维护良好且符合您需求的替代方案时。
- 提取自己的代码：当代码提供独特的业务价值或特定功能时。
使用现有组件的好处：
- 减少维护： 让社区或供应商维护代码。
- 经过验证的质量： 受益于广泛的测试和使用情况。
- 积极开发： 获取新功能和安全更新。
- 成本节省： 避免常见功能的开发时间。
分解的最佳做法
从小处着手
- 从定义完善的低风险组件开始。
- 在处理复杂区域之前验证该过程。
保持向后兼容性
- 考虑分阶段迁移以最大程度地减少中断。
- 为使用服务的团队提供清晰的迁移路径。
文档组件边界
- 明确定义每个组件负责的内容。
- 文档接口和协定。
正确设置组件版本
- 使用 语义版本控制 来传达更改。
- 在主要版本中保持兼容性。
监视组件运行状况
- 跟踪使用情况以了解影响。
- 监视已分解组件的性能和可靠性。