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

2020-04-21 17:05:26 +08:00
 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

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

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

6084 次点击
所在节点    程序员
58 条回复
lhx2008
2020-04-21 17:07:45 +08:00
有啥区别，只是文件夹不同而已。。
hantsy
2020-04-21 17:08:23 +08:00
小项目用 1 就可以了。

大一点的项目必须用 2 结构，不同的 Domain 分开，也方便以后拆分。
ben1024
2020-04-21 17:14:27 +08:00
看迭代和人力交互
1.迭代速度快，人力交互略差，扩展性略差
2.迭代速度慢，人力交互方便，内部通信成本增加，扩展性好
hantsy
2020-04-21 17:16:29 +08:00
1 。不同的 Domain 之前， 一些本来有 Entity 耦合的情况，使用 ContextMapping 概念，用一些 Ref 代替
2 。Domain 之间调用切换到 Message Broker，或者 REST API 等。
Hanggi
2020-04-21 17:19:26 +08:00
@lhx2008
怎么说呢，感觉主要是依赖方式不同。

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

不知道这么说对不对。
huijiewei
2020-04-21 17:19:36 +08:00
用结构 2 吧

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

更加灵活
gemini767
2020-04-21 17:20:13 +08:00
个人认为没啥区别，团队统一好了

大应用拆应用
opengps
2020-04-21 17:22:18 +08:00
小系统选 1，大系统选 2，2 可以轻松的吧每一个业务板块单独拆出来
janda
2020-04-21 17:23:27 +08:00
第二种挺像 微服务中这样的的了！每个都是完全独立的
kaiser1992
2020-04-21 17:26:14 +08:00
DDD ？
Hanggi
2020-04-21 17:28:52 +08:00
@janda 实际操作中很难做到完全独立，比如 A 里的一个表跟 B 里的一个表有一对多的关系。那就会有一条依赖从 A 伸进 B 。
这种情况，一般怎么处理呢，到时候要拆的时候怎么拆呢？
index90
2020-04-21 17:29:52 +08:00
感觉没有区别啊
Hanggi
2020-04-21 17:33:17 +08:00
@index90 一种区别是，
1 。开发的时候你要在多个文件夹里跳来跳去，特别是文件数量超多的时候，会很烦。
2 。的话，所有相关联文件可能都在附近。
rioshikelong121
2020-04-21 17:38:59 +08:00
前端也是这样的吧。小项目第一种，比较大的项目第二种。
index90
2020-04-21 17:57:59 +08:00
@Hanggi 所以为什么你不分成多个 repo，而要堆在一起？
xcstream
2020-04-21 17:59:55 +08:00
混合 A 和 B 的模式
Hanggi
2020-04-21 18:07:44 +08:00
@index90 一个项目啊，比如 A 是用户模块，B 是文章模块，C 是视频模块，类似这么分，同一个项目怎么可能分在不同的 repo 呢。
lower
2020-04-21 18:22:13 +08:00
把两者结合一下：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
noobsheldon
2020-04-21 19:19:16 +08:00
@lower 这不就是 Django 的结构吗
Kirsk
2020-04-21 19:31:50 +08:00
从 service 开始按模块分
看业务有可能分两层 service
底下就是作为基础层 model
其实用 API 服务化的思维去做服务端我觉得比较合适
view 已经弱化了
这么分的理由是业务共性的东西会逐渐下沉形成比较稳定的层级或功能，service 层之上根据业务来

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/664709

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX