前言
- 一个应用，产生自同一个仓库。
- 一个仓库，只产生一个应用。
为什么推演出这么两个结论呢我们先看一个实际的项目。
为什么是一个应用/strong>
给大家举一个一个仓库包含多个应用的反例，笔者自己的一个项目是一个的微服务的架构，和大部分的微服务架构一样，一开始是由一个单体的应用拆解而来，拆解之后，大致简化成四个服务：微服务 关(Gateway)，两个后台服务(UserService, OrderService)，后台管理控制台服务(Admin)，简单的架构示意图如下：
这个故障，我先邀请大家一起思考一下几个问题：
- 从编码角度，如何避免上述重写的方法因为名字误写造成故障/li>
- 从设计角度，OrderUser 和 User，是否是继承关系/li>
- 这个问题的根因是什么/li>
以上的几个问题中，第一个问题的答案，很多同学都知道，就是使用 Java 自带的 Annotation @Override，他会自动强制去检查所修饰的方法签名在父子类中是否一致。第二个问题，需要从领域边界来说，这是一个典型的边界划分的问题，即：订单中的用户，和会员登录中的用户，是不是相同的“用户”员中的用户，其实只需要关心用户名密码，其他都是这个用户的属性；而订单中的用户，最重要的肯定是联系方式，即一个联系方式，确定一个人。虽然他们都叫做用户，但是在彼此的上下文中，肯定是不一样的概念。所以这里的 OrderUser 和 User 是不能用继承关系的，因为他们就不是一个 “IS A” 的关系。
仓库共享，加上没有多加思考的模型，导致依赖混乱；如果两个 User 对象之间代码上能做到隔离，不是那么轻易的产生“关系”，这一切或许可以避免。
为什么是一个仓库/strong>
为了解掉第一个问题，我们决定拆仓库，仓库的粒度按照应用粒度分，同时把 common 相关的都拆到一个叫做 common 仓库中去；业务服务都好说，这里特殊处理的是 admin 应用，admin 是一个后台管理应用，变化频度特别大，需要依赖 UserService 和 OrderService 一大堆的接口。关于和其他仓库接口依赖的处理，这里除了常见的 Maven 依赖方式之外，还有另外一个解决方案就是 git submodule，关于两个方案的对比，我简单罗列在了下表之中：
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！