模块化设计

REP 复用/发布等同原则

复用/发布等同原则（Reuse/Release Equivalency Principle）：软件复用的最小粒度应等同于其发布的最小粒度。 直白地说，就是要复用一段代码就把它抽成模块。

CCP 共同闭包原则

共同闭包原则（Common Closure Principle）：为了相同目的而同时修改的类，应该放在同一个模块中。 对大部分应用程序而言，可维护性的重要性远远大于可复用性，由同一个原因引起的代码修改，最好在同一个模块中，如果分散在多个模块中，那么开发、提交、部署的成本都会上升。

CRP 共同复用原则

共同复用原则（Common Reuse Principle）：不要强迫一个模块依赖它不需要的东西。 相信你一定有这种经历，集成了模块A，但模块A依赖了模块B、C。即使模块B、C 你完全用不到，也不得不集成进来。这是因为你只用到了模块A的部分能力，模块A中额外的能力带来了额外的依赖。如果遵循共同复用原则，你需要把A拆分，只保留你要用的部分。

复用原则竞争关系

REP、CCP、CRP 三个原则之间存在彼此竞争的关系。REP 和 CCP 是黏合性原则，它们会让模块变得更大，而 CRP 原则是排除性原则，它会让模块变小。遵守REP、CCP 而忽略 CRP ，就会依赖了太多没有用到的模块和类，而这些模块或类的变动会导致你自己的模块进行太多不必要的发布；遵守 REP 、CRP 而忽略 CCP，因为模块拆分的太细了，一个需求变更可能要改n个模块，带来的成本也是巨大的。

微服务设计原则

• 单一职责原则: 每个微服务应专注于单一功能或业务能力，确保服务的职责清晰和维护简单。

• 松耦合: 微服务之间的依赖应该最小化，这样可以独立地部署和扩展服务，而不会影响其他服务。

• 自治: 每个微服务应该是自治的，具有自己的数据库、API和独立的运行环境。

• 无状态设计: 微服务应尽量避免保存状态，这样可以更容易地进行水平扩展。

• 持续交付和部署: 微服务应支持持续集成、交付和部署，以加速开发和部署周期。

• 中央化服务配置: 服务的配置应从服务代码中分离出来，并集中管理，以便于运维和动态调整。

• 故障隔离: 单个微服务的失败不应影响其他服务的正常运行。

• 服务发现和注册: 微服务应能够自动注册到服务注册中心，并通过服务发现来找到其他服务。

• API网关: 为所有微服务提供统一的入口，实现请求路由、负载均衡和API聚合等功能。

模块化设计原则

• 高内聚: 模块内部的元素应该紧密相关，支持特定的功能或业务逻辑。

• 低耦合: 模块之间的依赖和交互应最小化，以确保模块的独立性和可替换性。

• 模块接口清晰: 每个模块都应该有一个清晰、稳定且文档齐全的接口，方便其他模块调用。

• 模块独立性: 模块应该是独立的，可以独立地开发、测试和部署。

• 模块复用性: 通过清晰的设计和接口定义，模块应具有高度的复用性。