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

[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

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

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

[huijiewei]

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

[wangyzj]

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

[wizardoz]

我只想说第一种很无脑

[0x49]

果断第二种

[janda]

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

[siganushka]

Symfony Bundles 了解一下

[mitu9527]

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

[Hanggi]

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

[Samuelcc]

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

[mitu9527]

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

[xuanbg]

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

[abcbuzhiming]

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

[nvkou]

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

[wweir]

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

[uxstone]

没有最优

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

[limingjie138]

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

[huijiewei]

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

[zhuzhibin]

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

[imycc]

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

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

[zclHIT]

来吧拥抱 DDD