从0开始做saas - 应用架构和基础架构的设计思路

（技术兄弟们帮忙给个关注，大家一起讨论）

当我们选择了用微服务架构去设计一个 SAAS 系统时，我们从一开始就应该考虑项目的架构，当划清了业务边界后，技术边界会变得清晰。接下来就可以考虑整体项目架构的设计了

原则一：边界不可能绝对清晰，对不同的意见应持吸取态度，是否采纳受当前阶段影响

原则二：公共部分的代码抽象类型要细分：业务类、基础类

原则三：少数派不构成公共，多数派不决定所有少数派

下面是一张参考项目架构描述了一个项目的内部细节：

以上主要描述了如何抽象公共包的思路，粒度还是比较粗糙的， 仅供参考。

内容主要分业务代码、业务公共代码、基础框架代码、基础框架服务治理依赖、基础框架平台级公共业务依赖。

其细节大致涵盖了日常工作中的大部分场景，并解决关于 dto\vo\feignclient \基础框架等如何管理的问题，及相关争执。

不成熟的架构设计，往往会深入自己的世界中，与外界不同意见唯一的交流是争执，例如有人说 共享feignclient 应该抽象成 jar 包， 也有反对意见说，对feignclient 的依赖过重，影响其他服务迭代。于是就争论了：

正方：feignclient 应该取消因为耦合严重影响其他服务迭代

反方：如果不耦合那么当改了接口的时候其他所有代码都要改

其实这个问题应该细化：什么样的 feignclient 会因为耦合而影响其他服务？有没有一些 feignclient 是允许被抽象成公共包的？

这个问题是有很大的争议的。 A little copying is better than a little dependency。对于依赖范围小的应该坚持复制为方向， 依赖大的才抽象成公共，最忌讳的就是不加思考一股脑全给抽象成公共，就两个系统间的业务常量也要抽象到 framework 里面自然是不适合的。

欢迎探讨。