This is the first article in a series on how the “verticalization” of large e-commerce platforms, and the migration to a microfrontend architecture, enables IT organizations to deliver value faster and with higher quality. The following articles will be published (and linked here) sometime in the near future.

这是有关大型电子商务平台的“垂直化”以及向微前端架构的迁移如何使IT组织更快，更高质量地交付价值的系列文章中的第一篇。 以下文章将在不久的将来发表(并链接到此处)。

Let’s assume we’re an international enterprise that sells a broad portfolio of goods via an e-commerce platform. The platform didn’t come out of nowhere, it has grown over the years. From a small online shop in the late nineties to the backbone of a “digital-first” enterprise that it is today. And the workforce around the platform has grown as well: From a small group of enthusiasts to an IT department of around 100 people across several teams and locations.

假设我们是一家通过电子商务平台销售广泛商品组合的国际企业。 该平台并非一帆风顺，多年来发展壮大。 从九十年代末的一家小型在线商店，到如今的“数字优先”企业的骨干。 平台周围的劳动力也在增长：从一小群爱好者到几个团队和地点的大约100人的IT部门。

The platform works great and is profitable; customers, management and IT people are generally happy. However, not everything is perfect: There’s a lot of communication overhead, product decisions tend to get very technical, onboarding is tedious, features take forever to be delivered.

该平台运作良好且有利可图； 客户，管理人员和IT人员通常都很满意。 但是，并非所有事情都是完美的：存在大量的通信开销，产品决策往往会变得技术性很强，入职乏味，功能永远需要交付。

Why is that?

这是为什么？

The answer lies in the technology of the platform and the effects it has on the organization and its workflows.

答案在于平台的技术及其对组织及其工作流程的影响。

敏捷性和适应性 (Agility and Adaptivity)

Agile development is certainly the prevalent paradigm in most areas of IT these days, especially in e-commerce. Markets change rapidly, and if you can’t respond to changes, you’re out. While there are very different interpretations of what “agile” means and how to do it, it is always useful to remember the agile principles, and especially Martin Fowler’s true words:

如今，敏捷开发无疑是大多数IT领域的普遍范例，尤其是在电子商务中。 市场瞬息万变，如果您无法应对变化，那就出局了。 尽管对“敏捷”的含义和用法有非常不同的解释，但记住敏捷原理尤其是马丁·福勒的真实话总是有用的 ：

“Agile development is adaptive rather than predictive.”

“敏捷开发是适应性而非预测性的。”

In regard to technology, adaptivity is the key characteristic of agility. A fair metric of adaptivity could be the combination of two factors:

关于技术， 适应性是敏捷性的关键特征。 一个公平的适应性指标可以是两个因素的组合：

1. How short are your delivery cycles? (A month? A week? A day? An hour?)您的交货周期有多短？ (一个月？一个星期？一天？一个小时？)
2. How much net increase in customer value can you deliver per cycle, assuming a constant size of your workforce?假设员工人数不变，您每个周期可以带来多少客户价值净增加？

Obviously, the shorter the delivery cycle is, and the higher the value delivery per cycle is, the more adaptive is a platform.

显然，交付周期越短，每个周期的价值交付就越高，平台的适应性就越强。

Unfortunately, many platforms that have grown over the years are not really adaptive, due to the underlying architecture.

不幸的是，由于基础架构的原因，多年来发展起来的许多平台并不是真正的自适应。

分层架构 (Layered Architectures)

A typical web application is built as a so-called multi-tier (or, “layered”) application. As the name suggests, it consists of layers, where each layer implements a set of similar technical concerns, and is decoupled from other layers with different concerns. Each layer consists of modules, i.e. building blocks which implement the functionality of a layer. (Some environments use different terms than layer/module, but they mean the same.)

典型的Web应用程序被构建为所谓的多层(或“分层”)应用程序。 顾名思义，它由多个层组成，其中每个层都实现了一组类似的技术关注点，并且与其他具有不同关注点的层分离。 每个层都由模块 (即，实现层功能的构建块)组成。 (某些环境使用的术语与层/模块不同，但含义相同。)

For example, a “presentation” layer will have modules for displaying texts, images, forms and other user interface features. A “business logic” layer contains modules to calculate prices, check inventory, process orders, manage user accounts.

例如，“表示”层将具有用于显示文本，图像，表单和其他用户界面功能的模块。 “业务逻辑”层包含用于计算价格，检查库存，处理订单，管理用户帐户的模块。

An important aspect of the layer concept is that modules in higher layers may have dependencies on modules in their own or in lower layers, but not on modules in higher layers. This way, you can significantly reduce interdependencies in your ecosystem and minimize the risks of something breaking.

层概念的一个重要方面是，较高层中的模块可能依赖于其自身或较低层中的模块，而不依赖于较高层中的模块。 这样，您可以显着减少生态系统中的相互依赖性，并最大程度地降低破坏某些事物的风险。

电子商务平台的演变 (The Evolution of E-Commerce Platforms)

At the beginning, an e-commerce platform has only few layers and it is usually “monolithic”, meaning that there is exactly one deployable piece of software.

最初，电子商务平台只有几层，通常是“整体的”，这意味着只有一个可部署的软件。

As the platform grows, the next natural step is to separate the frontend from the backend. The frontend is a Single Page Application (SPA) which runs purely in the browser, while the backend still runs in a datacenter. Between the both, you have a webservice API, for example REST or GraphQL.

随着平台的发展，下一步自然是将前端与后端分离。 前端是仅在浏览器中运行的单页应用程序 (SPA)，而后端仍在数据中心中运行。 在这两者之间，您拥有一个Web服务API，例如REST或GraphQL。

As the platform grows even bigger, the backend is starting to „dissolve“, i.e. more and more functionality is extracted from the previously monolithic backend into isolated microservices. These are self-contained, very small applications with exactly one purpose which they expose through a webservice API.

随着平台的发展，后端开始“溶解”，即越来越多的功能从以前的整体后端提取到隔离的微服务中 。 这些都是独立的非常小的应用程序，其目的恰恰是通过Web服务API公开的。

At some point, the old backend has disappeared, and we now have a pure microservice backend, usually with an aggregation layer and/or API gateway in front of it.

在某个时候，旧的后端已经消失了，现在我们有了一个纯微服务后端，通常在其前面有一个聚合层和/或API网关。

There are variations and extensions of this concept, but the basic principle is always the same: There’s a tight horizontal coupling (of modules within one layer), and a loose vertical coupling (of modules across layer boundaries). Therefore, we will subsume multi-tier, backend/frontend, and microservices architectures as horizontal ones.

此概念有多种变体和扩展，但基本原理始终相同：存在紧密的水平耦合(一层内的模块)和松散的垂直耦合(跨层边界的模块)。 因此，我们将多层，后端/前端和微服务架构归为水平架构。

A horizontal platform is one that has strong boundaries between modules in different layers, while it has weak boundaries between modules in the same layer.

水平平台是在不同层中的模块之间具有强边界的平台，而在同一层中的模块之间具有较弱的边界。

There’s nothing bad or wrong with horizontal systems. Up to a certain size of the organization and the platform, it is a natural way of building things. But it has inherent limitations, as we will see later.

水平系统没有什么坏处。 在组织和平台达到一定规模之前，这是构建事物的自然方法。 但是它具有固有的局限性，我们将在后面看到。

等等，您只是说微服务架构是水平的吗？ (Wait, Did You Just Say Microservice Architectures Are Horizontal?)

There, I said it: Even an SPA + microservice architecture is horizontal. Just look at it! The frontend is one big layered monolith, especially from a delivery perspective. Below that you have multiple layers of services, where some are public and some are shared or private. If you draw a dependency graph between these components, it will resemble a layered architecture.

我在那里说过：即使SPA +微服务架构也是水平的。 看看吧！ 前端是一个大的分层整体，特别是从交付角度来看。 在其下方，您具有多层服务，其中一些是公共的，一些是共享的或私有的。 如果在这些组件之间绘制依赖关系图，它将类似于分层体系结构。

The are, however, two big advantages of microservices: 1. They can be maintained and deployed autonomously. 2. You have less of a technology lock-in (we’ll get back to this later). On the other hand, an enterprise-level microservice ecosystem is much more complex to maintain (think of service discovery, monitoring, tracing, etc.), and each microservice needs versioned APIs plus a set of internal resilience features such as circuit breakers.

但是，微服务有两个主要优点：1.它们可以自动维护和部署。 2.您的技术锁定较少(我们稍后会再讲)。 另一方面，企业级微服务生态系统的维护要复杂得多(请考虑服务发现，监视，跟踪等)，并且每个微服务都需要版本化的API和一组内部弹性功能(例如断路器)。

And even if the delivery of a single microservice is fast, the delivery of a feature requires a cascade of steps upwards through the platform layers until it is accessible to a customer.

而且即使单个微服务的交付速度很快，功能的交付也需要从平台层向上逐步向上进行一系列的步骤，直到客户可以访问它为止。

隐藏层 (The Hidden Layers)

Software ecosystems are often being described only from a runtime application perspective, meaning that the supporting functionality around the application is out of scope. But when we talk about dependencies and complexity, there are many hidden “layers”, which have similar behaviour and effects as the runtime layers. For example:

通常仅从运行时应用程序的角度描述软件生态系统，这意味着围绕应用程序的支持功能超出了范围。 但是，当我们谈论依赖关系和复杂性时，有许多隐藏的“层”，它们的行为和效果与运行时层相似。 例如：

• CI/CD pipelines are often built “one for all”: All modules within one layer use the same build/test/deploy pipeline. Sometimes even the entire platform uses one monolithic mega-pipeline which is able to deliver all parts of the platform. And, of course, this leads to software being bent to fit the pipeline — especially when the pipeline is managed by a dedicated team.CI / CD管道通常是“一劳永逸”的：一层内的所有模块都使用相同的构建/测试/部署管道。 有时，甚至整个平台都使用一条完整的巨型管道，该管道能够交付平台的所有部分。 而且，当然，这导致软件需要适应管道需求，尤其是当管道由专门团队管理时。
• Administration tools are usually “layered” as well. While you could argue that they usually have a rather narrow scope, like CMS, ERP or CRM tools, they are similar to microservices in that they have no implicit restriction on “incoming” dependencies, and therefore cannot simply adapt to changing requirements.管理工具通常也是“分层的”。 尽管您可能会争辩说它们通常具有相对狭窄的范围，例如CMS，ERP或CRM工具，但它们与微服务类似，因为它们对“传入”依赖项没有隐式限制，因此不能简单地适应不断变化的需求。
• The same is true for external dependencies. An e-commerce platform is connected to a plurality of other services such as payment providers, suppliers, shipment, performance marketing, web analytics and many more.外部依赖项也是如此。 电子商务平台连接到多个其他服务，例如支付提供商，供应商，运输，绩效营销，网络分析等等。

• Runtime infrastructure is often set up in a way that all modules within the same layer use the same infrastructure: one database for all data, one S3 bucket for all frontend artifacts, one EC2 + EKS cluster for all microservices. Fixing or updating parts of the infrastructure is complex and risky.

  运行时基础结构通常以一种方式设置，即同一层中的所有模块都使用相同的基础结构： 一个数据库用于所有数据， 一个 S3存储桶用于所有前端构件， 一个 EC2 + EKS集群用于所有微服务。 修复或更新基础架构的各个部分非常复杂且存在风险。

To understand the effects of such an architecture on the organization, let’s have a closer look at the development and delivery workflows.

为了了解这种体系结构对组织的影响，让我们仔细研究一下开发和交付工作流程。

水平架构，繁琐的工作流程 (Horizontal Architecture, Tedious Workflow)

For our scenario, we will assume an imaginary IT department and look at a typical workflow to implement a feature. Of course, this is simplified and hypothetical, but it is derived from real-world organizations, and the insights are well applicable in practice.

对于我们的方案，我们将假设一个虚构的IT部门，并研究实现功能的典型工作流程。 当然，这是简化和假设的，但它是来自现实世界的组织，并且这些见解在实践中非常适用。

As long as the platform is small, it is managable by one team with one backlog. But as it grows, frontend/backend/microservices each get their own backlogs and are assigned to different teams. The overall feature roadmap is maintained by a team of product managers (or whatever you call them), supported by architects and designers.

只要平台很小，一个团队就可以管理一次积压的订单。 但是随着增长，前端/后端/微服务每个都有自己的待办事项，并分配给不同的团队。 总体功能路线图由一组产品经理(或您所说的任何人)维护，并得到建筑师和设计师的支持。

Now imagine what happens when business has a new feature requirement:

现在想象一下，当业务具有新功能要求时会发生什么：

• A product manager discusses the feature with business, then makes a detailled description of the desired functionality.产品经理与业务人员讨论该功能，然后对所需功能进行详细说明。
• An architect specifies the necessary technical changes in the platform and how they are are integrated across all layers and/or microservices. A designer makes pixel-perfect mock-ups of every possible UI state.架构师指定平台中必要的技术更改，以及如何将其集成到所有层和/或微服务中。 设计人员为每个可能的UI状态制作像素完美的模型。
• After product managers, architects and designers agree on the specifications, the feature request is approved for implementation.在产品经理，架构师和设计师就规格达成一致后，功能请求即被批准实施。
• Each development team derives a set of tasks and start working on them in accordance with their backlog priorization. As soon as the last team has finished their implementation, the new feature is ready to be rolled out.每个开发团队都会派生一组任务，并根据其积压工作优先级开始进行处理。 一旦最后一个团队完成了实施，便可以推出新功能。
• Because we have changes in different parts of the platform, we do a lot of testing before the final customer roll-out. And a lot of bug-fixing. And re-testing again.由于我们在平台的不同部分进行了更改，因此在最终客户推出之前，我们进行了大量测试。 还有很多错误修复。 并再次测试。
• Finally, we’re ready to release!最后，我们准备发布！

Even if we assume that all of the above runs smoothly, the whole process takes several steps and feedback loops. Changes are quite risky, as the affected code base is very large, especially in the frontend.

即使我们假设以上所有操作均能顺利进行，整个过程仍需要几个步骤和反馈循环。 更改的风险很大，因为受影响的代码库很大，尤其是在前端。

In such an enironment, nobody can take ownership or responsibility for the platform: product managers, architects and designers have no real influence on the outcome, because they are too far from what’s happening. And developers, testers and operators have no real influence on the specifications.

在这种环境下，没有人可以承担平台的所有权或责任：产品经理，架构师和设计师对结果没有真正的影响，因为它们与正在发生的事情相去甚远。 开发人员，测试人员和操作人员对规范没有真正的影响。

设计师指定还是实施？ (Do Designers Specify or Implement?)

By the way, there’s an interesting observation to make when we look at the UX/UI team, and this is something we see far too often, sadly: Why do the designers make detailled UI mockups before the implementation? And shouldn’t the UI designers be part of the frontend team?

顺便说一句，当我们考察UX / UI团队时，有一个有趣的发现，这是我们经常看到的，可悲的是：为什么设计人员在实现之前制作详细的UI原型？ UI设计人员不应该加入前端团队吗？

This is a very common, and nevertheless flawed, organizational setup when you have a grown horizontal platform. The UI is being designed as part of the specification process, and is submitted to the developers as a … uh, what is it, actually? Is it a user story? No. Is it a non-functional requirement? No, again. It’s in fact an implementation task which has been finished before the implementation started.

当您拥有不断发展的水平平台时，这是一种非常常见且有缺陷的组织设置。 UI是作为规范过程的一部分进行设计的，并且作为……提交给开发人员……嗯，实际上是什么？ 这是用户故事吗？ 否。这是非功能性要求吗？ 不，再说一次。 实际上，这是一个实施任务，已在实施开始之前完成。

The reason for this workflow is that the product management is too far away from the development and doesn’t trust the developers to implement the feature correctly — or, to put it differently, product management reduces the risk of a never-ending feedback cycle by using UI design as a common specification language.

此工作流程的原因是产品管理与开发之间的距离太远，并且不信任开发人员正确地实现功能-或者，换句话说，产品管理通过以下方法降低了无休止的反馈周期的风险：使用UI设计作为通用规范语言。

But pushing a finished UI design as a “requirement” is a serious mistake: A designer might have overlooked technical implications which, in the worst case, render the designs worthless.

但是将完成的UI设计作为“要求”进行推销是一个严重的错误：设计师可能忽略了技术含义，在最坏的情况下，这些技术含义会使设计毫无价值。

Also, in many cases, pixel-perfect UI designs are a waste of time. If you have styleguide, a design system, and/or a UI component library, it’s better to add the designers to the frontend team and let them, in collaboration with the developers, come up with a good UI during the implementation.

同样，在很多情况下，像素完美的UI设计浪费时间。 如果您有样式指南，设计系统和/或UI组件库，最好将设计人员添加到前端团队中，并让他们与开发人员合作在实施过程中提供良好的UI。

适应性与技术锁定 (Adaptivity vs. Technology Lock-in)

The tedious workflow aside, large-scale horizontal platforms are not at all adaptive. The more monolithic parts it has, the worse they suffer from the technology lock-in.

除了繁琐的工作流程外，大规模的水平平台根本无法适应。 整体零件越多，受技术锁定的影响就越大。

• The company has already invested a lot into the code base and the underlying frameworks, and there’s an entangled web of dependencies between layers and/or microservices.该公司已经在代码库和底层框架上投入了大量资金，并且在层和/或微服务之间存在着一系列相互依存的依赖关系。
• You can’t pick the optimal tool/framework/library for the job, because it is incompatible with the existing ecosystem, and migration costs and risk would too high.您无法选择适合该工作的最佳工具/框架/库，因为它与现有的生态系统不兼容，并且迁移成本和风险过高。

• The platform is full of pseudo-features (i.e. features which don’t have any customer value by itself, but instead allow business to deal with historical quirks and the long delivery cycles) and anemic code (code has no business value and is only there to keep different development teams from stepping on each other’s feet).

  该平台充满了伪功能 (即，这些功能本身没有任何客户价值，而是允许企业处理历史怪癖和较长的交付周期)和贫乏代码 (代码没有业务价值，仅存​​在于此)以防止不同的开发团队站在一起。

Technology lock-in, platform complexity and waterfall organization are “adaptivity killers”: They increase the “time to market”, and they diminish the possible outcome.

技术锁定，平台复杂性和瀑布式组织是“适应性杀手”：它们增加了“上市时间”，并减少了可能的结果。

A possible solution to overcome the problems with horizontal architectures is verticalization, which will be covered in the next article of this series. Stay tuned!

解决水平体系结构问题的一种可能的解决方案是垂直化 ，这将在本系列的下一篇文章中介绍。 敬请关注！