软件系统从单体应用到多系统应用（水平拆分、垂直拆分）的架构演进方式，相信已经深入人心。服务化，高内聚低耦合。但是，经常发现，这些拆分之后的兄弟应用读取DB还是会存在藕断丝连的现象，没完全拆分干净。
示例如下：
之所有出现这种现象，推测有几个方面的原因
1 认为不要紧，不用拘泥于一些约束，直接写DAO操作DB反而效率更高，更灵活
2 项目开发时间压力较大，为快速实现，直接读写DB
3 数据库表归属不清晰，多个应用都有归属
最近在梳理这边应用域的系统问题时，发现也存在这种现象，同一个DB多个应用都在读写。同时也在思考这个问题，我们到底要不要坚守这个原则。某应用域下的DB，只能该应用可读写。
无规矩难成方圆，系统架构是有约定的。合理的约定需要遵守，否则，被动或者主动的违犯会对现有架构进行腐蚀，时间一长，难以维护。表面上看应用直接读取归属其他应用的DB，开发效率会高些，但是一来你已经在腐蚀现有架构，再则之后你需要感知非你应用域下的数据库模型变更，同时其他应用域模型变更需要通知到你，为已经拆分的解耦应用间添加了一个新的强耦合。之前我遇到过一个系统，把dao层的代码通过jar包共享出来了，解决重复编写dao代码的问题，但是每次数据模型有变更，都需要评估本应用和兄弟应用的影响面，非常难受。
软件架构和开发都讲求分层，数据模型处理是由相关归属应用来负责的，包括整个模型生命周期的完整、缓存的管理和对外服务提供的完整等。其他非模型归属的应用，如果涉及到这块业务，关心的是服务的使用，不用涉及到底层Manager和DAO的细节实现。其实这也是一种分层，数据模型处理层和模型服务使用层，底层模型处理和上层模型服务使用层解耦，两者通过服务接口协议交互。上下层都遵循这份接口协议，自行在各自的分层下迭代改进，容易扩展。如下图示例
