每次调试都必须clean_如何使用“ The Clean Architecture”每次编写健壮的应用程序...

每次调试都必须clean

by Daniel Oliveira

丹尼尔·奥利维拉(Daniel Oliveira)

如何使用“ The Clean Architecture”每次编写健壮的应用程序 (How to write robust apps every time, using “The Clean Architecture”)

As developers, we can’t keep from using external libraries and frameworks in our systems. The community’s hands build marvelous tools, and using them is only natural. However, everything has a downside.

作为开发人员，我们无法避免在系统中使用外部库和框架。 社区的手在打造奇妙的工具，并且使用它们是自然而然的。 但是，一切都有缺点。

Careless teams and individuals can get in a dangerous situation by structuring their systems around the tools they use. Business rules get mixed up with implementation details. This can result in a brittle system, hard to extend and maintain. What should be a quick change in the GUI ends up turning into a bug hunt that lasts for hours. But it does not have to be like this.

粗心的团队和个人可能会因围绕使用的工具构建系统而陷入危险境地。 业务规则与实现细节混在一起。 这会导致系统脆弱，难以扩展和维护。 GUI中应该进行的快速更改最终变成了持续数小时的错误搜寻。 但是不必一定是这样。

Software Architecture proposes models and rules to determine the structures (like classes, interfaces, and structs) in a system and how they relate to each other. These rules promote reusability and the separation of concerns for these elements. This makes it easy to change implementation details such as the DBMS or front-end library. Refactors and bug fixes affect as little parts of the system as possible. And adding new features becomes a breeze.

软件体系结构提出了模型和规则，以确定系统中的结构(如类，接口和结构)以及它们之间的关系。 这些规则促进了可重用性以及这些元素的关注点分离。 这使得更改实施细节(例如DBMS或前端库)变得容易。 重构和错误修复影响尽可能少的系统部分。 并且添加新功能变得轻而易举。

In this article, I will explain an architecture model proposed in 2012 by Robert C. Martin, Uncle Bob. He is the author of classics like Clean Code and The Clean Coder. In October of this year, he’ll launch another book, Clean Architecture.

在本文中，我将解释由Robert C. Martin和Bob叔叔 于2012年提出的架构模型 。 他是Clean Code和Clean Coder等经典著作的作者。 今年10月，他将发行另一本书《 清洁建筑》 。

The model has the same name as the book, and it’s built on simple concepts:

该模型与书名相同，它基于简单的概念构建：

Divide the system’s composition into layers with distinct and well-defined roles. And restrain the relationships between entities in different layers. There’s nothing new in splitting your application in layers. But I chose this approach as it was the one that was the simplest to grasp and execute. And it makes testing use cases dead simple.

将系统的组成划分为具有不同且定义明确的角色的层。 并限制不同层次实体之间的关系。 将应用程序分成几层没有什么新鲜的。 但是我选择了这种方法，因为它是最容易掌握和执行的方法。 它使测试用例变得简单。

We just have to make sure the Interactors work properly, and we’re good to go. Don’t worry if the word “Interactors” seemed alien to you, we will learn about them soon.

我们只需要确保Interactors可以正常工作，就可以了。 如果您对“ Interactors”一词陌生，请不要担心，我们将尽快了解它们。

From inside out, we are going to explore each of the layers a bit further. We’ll use a sample application that’s quite familiar to us: counters. It takes no time to understand, so we can focus on this article’s subject.

从内而外，我们将进一步探索每个图层。 我们将使用一个我们非常熟悉的示例应用程序：计数器。 它不需要花时间来理解，因此我们可以专注于本文的主题。

You can find a demo of the app here, and the code samples will be in TypeScript. Some of the code gists below use React and Redux. Some knowledge about these solutions can help in understanding them. Yet, Clean Architecture’s concepts are much more universal. You will be able to understand it even without previous knowledge of the mentioned tools.

您可以在此处找到该应用程序的演示，并且代码示例将在TypeScript中。 下面的一些代码要点使用React和Redux。 有关这些解决方案的一些知识可以帮助理解它们。 但是，Clean Architecture的概念更为通用。 即使您以前不知道所提到的工具，也可以理解它。

实体 (Entities)

Entities are in the diagram as Enterprise Business Rules. Entities include business rules that are universal to a company. They represent entities that are basic to its area of operation. They are the components with the highest level of abstraction.

实体在图中作为“企业业务规则”。 实体包括公司通用的业务规则。 它们代表了其运营领域的基础实体。 它们是最高抽象级别的组件。

In our counters sample, there’s a very obvious Entity: the Counter itself.

在我们的计数器样本中，有一个非常明显的实体： Counter本身。

用例 (Use Cases)

Use Cases are pointed out as Application Business Rules. They represent each of the use cases of a single application.Each element of this layer provides an interface to the outer layer and act as a hub that communicates with other parts of the system. They’re responsible for the complete execution of the use cases and are commonly called Interactors.

用例被指出为应用程序业务规则。 它们代表单个应用程序的每个用例。该层的每个元素都提供了与外层的接口，并充当与系统其他部分进行通信的集线器。 他们负责用例的完整执行，通常称为交互器。

In our sample, we have a Use Case for incrementing or decrementing our counter:

在我们的示例中，我们有一个用例来incrementing或decrementing counter ：

Note that the factory function for ChangeCounterInteractor receives a parameter of the type CounterGateway. We will discuss the existence of this type will later in the article. But we can say that Gateways are what stands between Use Cases and the next layer.

请注意， ChangeCounterInteractor的工厂函数接收类型为CounterGateway的参数。 我们将在本文后面讨论这种类型的存在。 但是我们可以说网关是介于用例和下一层之间的东西。

接口适配器 (Interface Adapters)

This layer consists of the boundary between the system’s business rules and the tools that allow it to interact with the external world, like databases and graphical interfaces. Elements in this layer act as mediators, receiving data from one layer and passing it forward to the other, adapting the data as needed.

该层由系统的业务规则和允许其与外部世界进行交互的工具(例如数据库和图形界面)之间的边界组成。 该层中的元素充当中介者，从一个层接收数据并将其转发给另一层，并根据需要调整数据。

In our sample, we have several Interface Adapters. One of them is the React component that presents the Counter and its controls to increment and decrement:

在我们的示例中，我们有几个接口适配器。 其中之一是React组件，它提供Counter及其increment和decrement控件：

Note that the component does not use a Counter instance to present its value, but an instance of CounterViewData instead. We’ve made this change to decouple presenting logic from business data. An example of this is the logic of exhibition of the counter based on the view mode (Roman or Hindu-Arabic numerals). An implementation of CounterViewData follows below:

请注意，该组件不使用Counter实例来显示其值，而是使用CounterViewData的实例。 我们进行了此更改，以使呈现逻辑与业务数据脱钩 。 一个例子是基于视图模式(罗马或印度阿拉伯数字)的柜台展示逻辑。 CounterViewData的实现如下：

Another example of an Interface Adapter would be our application’s Redux implementation. Modules responsible for requests to a server and the use of local storage would also live inside this layer.

接口适配器的另一个示例是我们应用程序的Redux实现。 负责服务器请求和本地存储使用的模块也将驻留在此层中。

框架和驱动 (Frameworks and Drivers)

The tools your system uses to communicate with the external world compose the outermost layer. We don’t usually write code in this layer, that includes libraries such as React/Redux, browser APIs, etc.

系统与外部世界进行通信所使用的工具构成了最外层。 我们通常不会在这一层中编写代码，包括诸如React / Redux，浏览器API之类的库。

依赖规则 (The Dependency Rule)

This division into layers has two main goals. One of them is to make clear the responsibilities of each part of the system. The other is to make sure that each of them fills their roles as independently from each other as possible. For this to happen, there’s a rule that states how the elements should depend on each other:

这种划分有两个主要目标。 其中一项是明确系统各部分的职责。 另一个是确保他们每个人都尽可能独立地扮演自己的角色。 为了做到这一点，有一条规则规定了元素应该如何相互依赖：

An element must not depend on any element belonging to a layer outside its own.

元素不得依赖于属于其自身外部图层的任何元素。

For example, an element in the Use Cases layer can’t have any knowledge about any class or module related to GUI or data persistence. Likewise, an Entity can’t know which Use Cases make use of it.

例如，“用例”层中的元素不具有与GUI或数据持久性相关的任何类或模块的任何知识。 同样，实体不知道哪些用例在使用它。

This rule may have raised questions in your head. Take a Use Case, for example. It’s triggered as result of user interaction with the UI. Its execution involves the update in some persistent data storage such as a database. How can the Interactor make the relevant calls to the update routines without depending on an Interface Adapter that’s responsible for data persistence?

这条规则可能使您产生疑问。 以一个用例为例。 它是由于用户与UI交互而触发的。 它的执行涉及某些持久性数据存储(例如数据库)中的更新。 交互器如何在不依赖于负责数据持久性的接口适配器的情况下对更新例程进行相关调用？

The answer lies in an element that we’ve mentioned before: Gateways. They’re responsible for establishing the interface needed by the Use Cases to do their jobs. Once they’ve established this interface, it’s up to the Interface Adapters to fulfill their side of the contract, as shown in the diagram above. We have the CounterGateway interface and a concrete implementation using Redux below:

答案在于我们之前提到的元素： Gateways 。 他们负责建立用例完成工作所需的接口。 一旦他们建立了这个接口，就由接口适配器来履行其合同，如上图所示。 我们具有CounterGateway接口和以下使用Redux的具体实现：

您可能不需要它 (You may not need it)

Of course, this sample application was somewhat over complicated for an increment/decrement counter app. And I’d like to make clear that you do not need all this for a small project or prototype. But trust me, as your application gets bigger you’ll want to maximize reusability and maintainability. Good software architecture makes projects resistant to the passing of time.

当然，对于递增/递减计数器应用程序，此示例应用程序有些复杂。 我想明确指出，对于一个小型项目或原型，您不需要所有这些。 但是请相信我，随着您的应用程序变得更大，您将需要最大程度地提高可重用性和可维护性。 良好的软件体系结构使项目可以抵抗时间的流逝。

好吧...那又如何呢？ (Okay… So what?)

With this article, we discovered an approach to decouple our systems’ entities. This makes them easier to maintain and extend. For example, to build the same application using Vue.js, we would only have to rewrite CounterPage and CounterWidget components. The source code of the sample application is in the link below:

通过本文，我们发现了一种分离系统实体的方法。 这使它们更易于维护和扩展。 例如，要使用Vue.js构建相同的应用程序，我们只需要重写CounterPage和CounterWidget组件。 示例应用程序的源代码在下面的链接中：

Valbrand/counter-clean-architectureContribute to counter-clean-architecture development by creating an account on GitHub.github.com

Valbrand / counter-clean-architecture 通过在GitHub上创建一个帐户来促进反清洁架构的开发。 github.com

This story was translated to Portuguese by me! It is available here.

我把这个故事翻译成葡萄牙语！ 在这里可用。

What pros and cons do you see in this approach? Have you used something similar in production? Share your experiences in the responses. If you like the article, please clap for me!

您在这种方法中看到什么利弊？ 您在生产中使用过类似的东西吗？ 在回应中分享您的经验。 如果您喜欢这篇文章，请为我鼓掌！

翻译自: https://www.freecodecamp.org/news/how-to-write-robust-apps-consistently-with-the-clean-architecture-9bdca93e17b/

每次调试都必须clean