为了提高交付率并获得持续交付能力，在设计系统架构时应考虑以下激励措施：
为测试而设计：如果我们每次写代码都需要花费大量的精力，做大量的规划工作来测试它，那么从写代码到完成质量验证需要很长的时间，这实际上是困难的快点释放。
为部署而设计：如果我们开发一个新功能，在部署发布时，需要很长的准备时间，甚至可能需要停机部署软件系统的架构，导致难以快速发布。
专为监控而设计：如果我们的功能上线了，就很难监控，只能通过用户反馈来发现问题。 这样一来，持续交付的利润就会大幅减少。
为扩展而设计：这里的扩展性是指两个方面，一是支持团队成员规模的扩展，二是支持系统本身的扩展。
失败设计：俗话说：“走在沙滩上，鞋子不可能不湿。” 快速部署和发布总会出现问题。 为此，在开发软件功能之前软件系统的架构，应该考虑的一个问题是：一旦部署或发布失败，如何优雅、快速地处理。
系统拆分原理
一个大型系统应该由许多组件或服务组成。 组件一般在编译或部署时集成在一起，而服务则可以由多个组件组成，这些组件可以独立启动和运行，在运行时与整个系统进行通信，成为整个系统的组成部分。
在系统拆分的同时，我们还必须完善相应的建立、测试、部署和检测机制。 然而，这一机制的完善与制度的分裂同样重要。 只有这样，您才能获得系统分解的好处，同时管理分解带来的复杂性。
常见架构模式 架构重构执行模式
为了实现持续交付并增加架构修改的风险，建议团队根据实际情况采用击败者模式或修复者模式对遗留系统进行架构改造。
如何拆分数据库
