Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Little changes about translation #8

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -235,9 +235,9 @@ Rails 可以在很多场景下使用,但最初是用来做整合系统的 [Maj

系统开发的复杂度多半是引入了系统组件之间的界限,比如现在 A 组件该如何和 B 组件进行相互调用。本地组件之间的方法调用要远比 Microservices 之间的远程调用来得简单。Microservices 是另一个存在失败状态、延长问题,依赖更新周期的新场景(需要对比原文理顺,有点不太对),有许多潜在的问题等着尝试拆分的人去冒险。

当然有时候这种服务的拆分是必要的。若想建立让大家可以透过 HTTP 实用的 API,好吧,那你就得毫无怨言的处理许多的问题(虽然处理进来的请求比发出去请求要单一,但要是你的服务挂了,别人就会收到错误的状态了)。但这至少对你个人的开发体验伤害有限。
当然有时候这种服务的拆分是必要的。若想建立让大家可以透过 HTTP 调用的 API,好吧,那你就得毫无怨言的处理许多的问题(虽然处理进来的请求比发出去请求要单一,但要是你的服务挂了,别人就会收到错误的状态了)。但这至少对你个人的开发体验伤害有限。

更糟糕的是,当系统过早解耦,或是过早拆成小服务,以及更糟糕地拆成 Microservices。这是现代网络应用的错误认知,你只会反复地重造系统:同样的功能在后端做一次,在前端再做一次,在 Native 手机端又再次实现一次等等。这不是自然规律,你也不需要这样。
更糟糕的是,当系统过早解耦,或是过早拆成小服务,以及更糟糕地拆成 Microservices的时候。这种行为通常起源于一个错误的观念,即如果你想做一个现代网络应用,你需要做的只是反复地重造系统:同样的功能在后端做一次,在前端再做一次,在 Native 手机端又再次实现一次等等。这不是自然规律,你也不需要这样。

若想在整个应用里共享大部分的功能,这完全是可行的。桌面应用和 Mobile App 可以用同样的 Controller 和 View。尽可能地把功能集中在 Majestic Monolith - 整合系统。集中在一起完全不需要牺牲构建速度,开发者体验,以及其它错让你以为要尽早拆分系统的因素。

Expand Down