目前是目前系统内有n个应用，web的，后台服务的，分别由不同的人开发
互相之间有2种方式传递信息
- 通过RabbitMQ，互相之间通过发送json报文
- 通过数据库，web这里写表插一条记录，给后面服务一个id，后面服务去根据id读
这两种方式各有所长，
第一种方式各个模块之间的接口比较清晰，语义明确，但是系统中有冗余数据，每个模块都
要自己维护一份数据。
第二种方式数据层面是统一了，但现在数据库成为接口，而一旦语义层面发生变化，后期新
的维护者加入，换人修改，就不知道谁应该改动哪些数据，可维护性差很多。
不知道大家有没有碰到过这种问题，是怎么权衡的？是需要写更多的文档吗？
不同的系统有不同的设计方案，比如一个公司在不断发展壮大，注册量非常庞大，而基于这些用户开发的系统也越来越多，那就势必要求成立一个独立的团队，开发一个用户中心。其他项目使用的时候就调用这个用户中心提供的接口，这样也确保了数据的安全，同时也让项目开发更便捷，不至于东一套西一套的。举个例子：链接描述 这个项目提供的是统一的后端服务，使用这个后端服务的开发者/项目6w+，如何协调不同项目之间的信息传递？那就是restapi借口了。
不知道上面有没有说明清楚我的观点，也就是：不赞成第二张方案，而是通过添加新的一层，让系统更稳健，可维护性也越强。不同的层之间肯定有各自的业务逻辑，自然有一些自己的独立数据，这个并不影响。
谢谢，目前我们的做法基本上是个折衷方案，通过数据库来交换数据，但规定了哪些表归哪些模块写，其他模块只读。