快速 开发平台 架构_快速介绍清洁架构

快速 开发平台 架构

by Daniel Deutsch

由Daniel Deutsch

快速介绍清洁架构 (A quick introduction to clean architecture)

In an open source project I started to contribute to, the concept of “clean architecture” was brought to me.

在一个我开始参与的开源项目中 ，“清洁建筑”的概念被带给了我。

First, it was pretty overwhelming, but after some reading it made sense. I thought it might be helpful for others if I wrote down my thoughts.

首先，它非常令人难以理解，但是经过一番阅读之后，它才有意义。 我认为如果我写下自己的想法对他人可能会有帮助。

目录 (Table of Contents)

• Visual representations

  视觉表现

• The concept — presented in bullet points

  概念-以要点表示

• Code example

  代码示例

• Resources

  资源资源

视觉表现 (Visual representations)

I think it’s always good to start with some visualization.

我认为从一些可视化开始总是好事。

Here are the most common pictures of this concept.

这是此概念的最常见图片。

概念-以要点表示 (The concept — presented in bullet points)

Extended from Source and credit: Mattia Battiston, under CC BY 4.0

摘自来源和信誉： Mattia Battiston，根据CC BY 4.0

它可以提供的价值 (The value it can provide)

• An effective testing strategy that follows the testing pyramid
  遵循测试金字塔的有效测试策略
• Frameworks are isolated in individual modules. When (not if) we change our mind, we only have to make a change in one place. The app has use cases rather than being tied to a CRUD system
  框架隔离在各个模块中。 当(如果不是)我们改变主意时，我们只需要在一个地方进行更改即可。 该应用程序具有用例，而不是绑定到CRUD系统
• Screaming architecture a.k.a. it screams its intended usage. When you look at the package structure, you get a feel for what the application does rather than seeing technical details
  尖叫的架构又称它的预期用途。 当您查看包的结构时，您会感觉到应用程序的功能，而不是看到技术细节
• All business logic is in a use case, so it’s easy to find and not duplicated anywhere else
  所有业务逻辑都在用例中，因此很容易找到并且在其他任何地方都不会重复
• Hard to do the wrong thing because modules enforce compilation dependencies. If you try to use something that you’re not meant to, the app doesn’t compile
  很难做错事情，因为模块会强制执行编译依赖关系。 如果您尝试使用不需要的内容，则该应用程序将无法编译
• It is always ready to deploy by leaving the wiring up of the object for last. Or by using feature flags, so we get all the benefits of continuous integration
  通过将对象的布线留到最后，可以随时进行部署。 或通过使用功能标志，这样我们就可以获得持续集成的所有好处
• Multiple works on stories so that different pairs can easily work on the same story at the same time to complete it quicker
  多个故事作品，以便不同的配对可以轻松地同时处理同一个故事，从而更快地完成故事
• Good monolith with clear use cases that you can split in microservices later on, once you’ve learned more about them
  具有清晰用例的良好整体，一旦您了解了更多有关微服务的信息，便可以在以后将其拆分

实体 (Entities)

• Represent your domain object
  代表您的领域对象
• Apply only logic that is applicable in general to the whole entity (e.g., validating the format of a hostname)
  仅应用通常适用于整个实体的逻辑(例如，验证主机名的格式)
• Plain objects: no frameworks, no annotations
  普通对象：无框架，无注释

用例 (Use Cases)

• Represent your business actions: it’s what you can do with the application. Expect one use case for each business action
  代表您的业务行为：这就是您可以使用该应用程序执行的操作。 预期每个业务操作都有一个用例
• Pure business logic, plain code (except maybe some utils libraries)
  纯业务逻辑，纯代码(也许某些utils库除外)
• The use case doesn’t know who triggered it and how the results are going to be presented (for example, could be on a web page, or — returned as JSON, or simply logged, and so on.)
  用例不知道是谁触发了它，以及结果将如何显示(例如，可能在网页上，或者-以JSON返回，或者只是记录下来，等等)。
• Throws business exceptions
  引发业务异常

接口/适配器 (Interfaces / Adapters)

• Retrieve and store data from and to a number of sources (database, network devices, file system, 3rd parties, and so on.)
  从多个源(数据库，网络设备，文件系统，第三方等)检索数据并将数据存储到其中。
• Define interfaces for the data that they need in order to apply some logic. One or more data providers will implement the interface, but the use case doesn’t know where the data is coming from
  为它们需要应用某种逻辑的数据定义接口。 一个或多个数据提供者将实现该接口，但用例不知道数据来自何处
• Implement the interfaces defined by the use case
  实现用例定义的接口
• There are ways to interact with the application, and typically involve a delivery mechanism (for example, REST APIs, scheduled jobs, GUI, other systems)
  与应用程序进行交互的方式很多，通常都涉及一种交付机制(例如，REST API，计划的作业，GUI，其他系统)
• Trigger a use case and convert the result to the appropriate format for the delivery mechanism
  触发用例并将结果转换为交付机制的适当格式
• the controller for a MVC
  MVC的控制器

外部介面 (External Interfaces)

• Use whatever framework is most appropriate (they are going to be isolated here anyway)
  使用最合适的框架(无论如何它们都将在这里被隔离)

代码示例 (Code example)

See the structure on GitHub.

请参阅GitHub上的结构。

First of all, it is important to understand that clean architecture is a bundle of organising principles. So therefore everything is open to personal adjustments as long as core ideas are kept intact. The linked repository is a fork of the original project that brought this architecture design idea to me. Feel free to check out the original project as well, as it reflects further improvements.

首先，重要的是要了解干净的体系结构是一整套组织原则。 因此，只要保持核心思想不变，一切都可以进行个人调整。 链接的存储库是原始项目的分支，该项目将这个体系结构设计思想带给了我。 也可以随时检查原始项目，因为它反映了进一步的改进。

The webminer folder is structured into the basic layers:

webminer文件夹分为以下基本层：

1. entities
   实体
2. use_cases
   用例
3. interfaces_adapters
   interfaces_adapters
4. external_interfaces
   external_interfaces

It shall reflect the very basic approach for the design pattern.

它应反映出设计模式的最基本方法。

• Starting from entities, you can see that the core model of this project is the arxiv_document

  从entities开始，您可以看到该项目的核心模型是arxiv_document

• The next folder, use_cases shows our use case, namely to request the arxiv page

  下一个文件夹use_cases显示了我们的用例，即请求arxiv页面

• After that, we go through the interface_adapters folder that provides adapters for process requests in a REST application or for serializing

  之后，我们浏览interface_adapters文件夹，该文件夹为REST应用程序中的流程请求或序列化提供适配器

• The final and last layer is external_interfaces. This is where we use the flask server to implement the REST functionality

  最后一层是external_interfaces 。 这是我们使用Flask服务器实现REST功能的地方

All of those layers are dependent on the core layers but not the other way around.

所有这些层都依赖于核心层，而不是相反。

One important note: This is not 100% correctly implemented in the repository.

重要注意事项：这不是在存储库中100％正确实现的。

Why? Because the use cases are actually different. In reality the main use case is to provide the structured data. Another use case is to get the data from the arxiv page.

为什么？ 因为用例实际上是不同的。 实际上，主要用例是提供结构化数据。 另一个用例是从arxiv页面获取数据。

Did you spot this error in the architecture? If yes, congratulations! Not only did you bring enough curiosity to this article but you likely understand the principles well enough to build your own case and apply the concepts in reality!

您在架构中发现此错误了吗？ 如果是的话，恭喜！ 您不仅为本文带来了足够的好奇心，而且您可能充分理解了这些原理，可以建立自己的案例并在现实中应用这些概念！

Do you agree? If not, why? Thanks for reading my article! Feel free to leave any feedback!

你同意吗？ 如果没有，为什么？ 感谢您阅读我的文章！ 随时留下任何反馈！

翻译自: https://www.freecodecamp.org/news/a-quick-introduction-to-clean-architecture-990c014448d2/

快速 开发平台 架构