I claim that you want to start communicating between independent modules no sooner than you absolutely HAVE to, and that you should avoid splitting things up until you really need to, because that communication complexity often swamps the complexity of the actual pieces involved in it.
Linux, 2003
架构的本质是管理复杂性
- 架构的本质是为了管理复杂性。复杂性的来源是当前的业务需求和未来变化的不确定性
- 架构的本质就是对系统进行有序化重构，不断减少系统的“熵”，使系统不断进化。
- 架构的本质就是对系统进行有序化重构，以符合当前业务的发展，并可以快速扩展。
设计模式
可复用性
可复用性可能导致耦合：
过度通用化：为组件设计高度通用的接口，这些接口可能需要许多配置选项或依赖项以适应各种使用场景。这种设计往往会导致组件间的强耦合，因为改变一个组件可以影响到依赖它的所有其他组件。
共享状态：可复用组件如果设计为共享状态或数据，那么各个使用该组件的部分之间就有了隐含的依赖关系，这种设计容易导致耦合和非预期的副作用，使得系统行为难以预测和控制。
细粒度依赖：为了实现代码复用，可能会创建一些细粒度的组件或模块，这些小的组件被多个地方重复引用，形成复杂的依赖链。这种依赖关系的复杂性会增加修改和维护的难度。
如何避免耦合：
接口隔离：遵循接口隔离原则，为不同的使用场景设计专门的接口，确保组件之间仅通过最小且必要的接口进行交互。这有助于减少不必要的依赖和耦合。
依赖注入：通过依赖注入的方式，动态地将依赖关系从外部传入组件，而不是在组件内部硬编码依赖关系。这种做法提高了组件的独立性和可复用性，同时降低了耦合度。
模块化和封装：设计时应该注意模块化和封装原则，确保模块或组件之间的交互通过定义良好的接口进行，而不是暴露内部实现细节。这有助于降低模块之间的直接依赖，从而减少耦合。
设计模式的应用：合理运用设计模式，如工厂模式、策略模式等，可以更好地组织代码结构，明确组件职责，减少组件之间的直接依赖，有效控制耦合。