目前哪种服务端架构模式最优？

有啥区别，只是文件夹不同而已。。

小项目用 1 就可以了。

大一点的项目必须用 2 结构，不同的 Domain 分开，也方便以后拆分。

看迭代和人力交互
1.迭代速度快，人力交互略差，扩展性略差
2.迭代速度慢，人力交互方便，内部通信成本增加，扩展性好

1 。不同的 Domain 之前， 一些本来有 Entity 耦合的情况，使用 ContextMapping 概念，用一些 Ref 代替
2 。Domain 之间调用切换到 Message Broker，或者 REST API 等。

@lhx2008
怎么说呢，感觉主要是依赖方式不同。

1. 的话是一种网状依赖，相互之间的依赖关系不明确。
而 2. 会把重度依赖的放一起，轻度依赖的分开来。

不知道这么说对不对。

用结构 2 吧

小项目就打包成一个
大项目就分开打包

更加灵活

个人认为没啥区别，团队统一好了

大应用拆应用

小系统选 1，大系统选 2，2 可以轻松的吧每一个业务板块单独拆出来

第二种挺像 微服务中这样的的了！每个都是完全独立的

DDD ？

@janda 实际操作中很难做到完全独立，比如 A 里的一个表跟 B 里的一个表有一对多的关系。那就会有一条依赖从 A 伸进 B 。
这种情况，一般怎么处理呢，到时候要拆的时候怎么拆呢？

感觉没有区别啊

@index90 一种区别是，
1 。开发的时候你要在多个文件夹里跳来跳去，特别是文件数量超多的时候，会很烦。
2 。的话，所有相关联文件可能都在附近。

前端也是这样的吧。小项目第一种，比较大的项目第二种。

@Hanggi 所以为什么你不分成多个 repo，而要堆在一起？

混合 A 和 B 的模式

@index90 一个项目啊，比如 A 是用户模块，B 是文章模块，C 是视频模块，类似这么分，同一个项目怎么可能分在不同的 repo 呢。

把两者结合一下：D


├── A
│ ├── Model
│ │ ├──Model_A1
│ │ ├──Model_A2
│ │ └──Model_A3
│ ├── Controller
│ │ ├──Controller_A1
│ │ ├──Controller_A2
│ │ └──Controller_A3
│ └── View
│ ├──View_A1
│ ├──View_A2
│ └──View_A3
├── B
│ ├── Model
│ │ ├──Model_B1
│ │ ├──Model_B2
│ │ └──Model_B3
│ ├── Controller
│ │ ├──Controller_B1
│ │ ├──Controller_B2
│ │ └──Controller_B3
│ └── View
│ ├──View_B1
│ ├──View_B2
│ └──View_B3
└── C
├── Model
├── Controller
└── View

@lower 这不就是 Django 的结构吗

从 service 开始按模块分
看业务有可能分两层 service
底下就是作为基础层 model
其实用 API 服务化的思维去做服务端我觉得比较合适
view 已经弱化了
这么分的理由是业务共性的东西会逐渐下沉形成比较稳定的层级或功能，service 层之上根据业务来

@Hanggi 项目不大就把所有模块集中到一起，项目大了考虑分离就去除依赖，使用 RPC 或者微服务

“服务端架构模式”？？？？？？

我只想说第一种很无脑

果断第二种

@Hanggi 这样每个项目之间进行通讯、需要一个注册中心、把多个集中在一起！这样就相当于 N 个模块、变成一个项目了！不过这样操作成本比较大、维护也比较麻烦的！大项目用这种比较好、小项目用你的 A 方法就行了

Symfony Bundles 了解一下

哪里有什么最优解决方案，只有最合适的解决方案。选择适合当下的方案，然后当需求变化时，改成适合新需求的方案。

@mitu9527 但是项目都是从小规模做起，到最后变多大往往也是无法预计的，到时候再重构不是成本更高吗？

个人喜欢第二种，通过 package private 的方式解耦各个模块，不会互相耦合，方便拆分和重构，也适合按照功能查找代码。

@Hanggi 就因为没办法预计，才应该选择最适合当下的。别人的也不见得适合你，就拿微服务来说吧，真正适合的公司就没多少家，服务数量都没上来就开始准备拆分，明显考虑的太早了。Keep It Simple 。

无脑选 2 就行。第一种非常容易写着写着就不清不楚地黏糊在一起了

@xuanbg 选 2 要面对一个预先规定功能边界问题，然而在经常变动的需求下就慢慢的这个边界就模糊了，然后你就发现照样糊在一起

后端不是已经没有 view 了吗。重点应该都在路由和业务了吧。

2, 不过拆分了 repo 。
整个使的是微服务的套路

没有最优

如果不对需求严加把控，最终都会变成💩山。

个人开发我选择了 1，但后来项目越堆越大，再开其他项目需要共用实体类的时候我就超级头痛，快点但蠢新建一个 project 把 enter 完整的 copy 过去。后悔当时不应该为了自己开发快选 1 。有没有大佬能救救我 1 的方案导致的实体不能多 project 共用的问题

@limingjie138 你这个问题，最简单地办法就是引入 RabbitMQ 独立事件机制，把关联做成事件关联

有区别吧 第二种是按照模块组织 最上层可以抽成通用的壳子 业务按照 modules 来组织 期望这些 module 都是独立可拆分的 这种做法比较难的就是业务解耦了 模块之间不要耦合太严重，否则没啥收益了

flask 的 blueprint 就是 2 这样的设计思路，每个模块之间各自处理内部的业务，在功能拆分还有迭代上会舒服一些。

不过即使用了 2 的结构，如果在开发时候 ABC 互相引用，到时候拆微服务也拆不开。

来吧拥抱 DDD

抛开项目需求谈架构都是扯

我来问个题外话，楼主你这个树形结构的图是怎么生成的？有时候分享 ppt 这种图还蛮清晰明了的

我和楼主同样的 两个模块之间耦合数据层（ Model ）该怎么办？需要连表的情况下，该如何处理呢？希望求得一知半解

这个叫代码结构

毫无疑问选 B

这只是代码组织方式而已，前端客户端都可以用。

没有完美的方式，只有最合适的方式，抛开需求谈这个没什么意义。

我怀疑你在说 tp3 和 tp5 哈哈哈

初期一个就行了，后期再拆分，遇到困难再想解决方案。。。

点链接之前脑子里闪现了分布式 无状态 高可用 一致性 ，点进来原来是代码放哪个文件夹。。。。。

业务划分得清楚，A 也可以重构成 B 。业务互相耦合，用 B 一样给写成 A 。

这不就是个文件目录吗? 怎么成服务器架构模式了!

@Muyiafan
@robot1
@Leigg
@wangyzj

好多人都在纠结为什么叫架构模式，可能翻译的不准确，但是我们平时经常说的 MVC 、微服务都是架构模式，贴个维基百科链接：
https://zh.wikipedia.org/wiki/%E6%9E%B6%E6%9E%84%E6%A8%A1%E5%BC%8F

当你改变你的目录结构、代码组织方式、依赖管理方式等这些细节的时候，其实你已经悄然改变了你的架构模式。

目录结构是跟着架构走的，还是得看实际需求，所以也谈不上哪种最优

混起来用，以 B 为主，A 为辅。

@Hanggi 单回复你那个多表关联下的模块拆分问题，我正好前阵子看过一个房产平台微服务视频，里面提了，说这种跨模块的，最好把关联表放到被依赖关系较小的那个库里，比如说用户表被很多模块依赖，那用户-房产关联表，就放到房产模块的库里

前者不就是后者的细节展开图嘛 ...

@abcbuzhiming 功能边界肯定要划分清楚的呀。

我在带团队的过程中一直强调，把代码写对地方比写对代码更重要。代码写错了很快就能发现并修复问题，写错了地方则不然，当时是没问题你好我好大家好，但会让你在后面一直吃屎。。。同时也会在合并分支时产生大量的冲突。

事实上只要在写代码之前稍微思考一下再动手，就很容易解决功能边界的问题，也就能把代码写对地方了。

@JaguarJack A 和 B 之外搞个 Common 就行，AB 都依赖 C