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

[Hanggi]

传统服务端项目都是使用一种分层架构模式（这里用 MCV 举例）：

.
├── Model
│   ├── Model_A
│   ├── Model_B
│   └── Model_C
├── Controller
│   ├── Controller_A
│   ├── Controller_B
│   └── Controller_C
└── View
    ├── View_A
    ├── View_B
    └── View_C

这种架构方式会有很多变种，但是大体结构相似，就是相同层级的文件会放在同一目录里。

最近，越来越多的项目使用一种以功能为边界的架构模式：

.
├── A
│   ├── Model
│   ├── Controller
│   └── View
├── B
│   ├── Model
│   ├── Controller
│   └── View
└── C
    ├── Model
    ├── Controller
    └── View

有种说法说这种架构模式方便日后微服务化。

如果主要以开发效率、维护成本、可扩展性等，这些核心需求来考虑，哪种架构模式更好更具发展性呢？

[realpg]

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

[hacson]

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

[JaguarJack]

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

[Leigg]

这个叫代码结构

[oneisall8955]

毫无疑问选 B

[AngryMagikarp]

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

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

[edk24]

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

[Jrue0011]

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

[robot1]

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

[Orenoid]

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

[Muyiafan]

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

[Hanggi]

@Muyiafan
@robot1
@Leigg
@wangyzj

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

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

[baiyi]

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

[xianxiaobo]

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

[zypy333]

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

[charlie21]

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

[xuanbg]

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

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

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

[xuanbg]

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