Below is the classical Clean Architecture diagram from Uncle Bobs original blog post.

下面是博布斯叔叔最初的博客文章中的经典清洁建筑图。

I am rather confused as to why the Gateways are more outwards than the Use Cases. This is something present in all such diagrams I have seen so far that include Gateways or some other form of Data Access mechanism.

我很困惑为什么Gateways比用例更外向。这是我到目前为止看到的所有这类图表中的一些东西，包括网关或一些其他形式的数据访问机制。

I understand that Use Cases should not bind to the specifics of the Data Access mechanism, as these should be hidden behind an architectural boundary. At the same time the only users of the services that form this boundary should be the Use Cases. That clashes hard with the diagram, as following the visual rules, Use Cases cannot use the Gateways (while they need to) and frameworky-stuff can use them (while it should not).

我理解用例不应该绑定到数据访问机制的细节，因为这些应该隐藏在体系结构边界之后。同时，形成此边界的服务的唯一用户应该是用例。这与图表严重冲突，因为遵循视觉规则，用例不能使用网关(当它们需要时)，而框架工作人员可以使用它们(虽然它不应该使用)。

Am I missing something? And if not, is there a more correct way to represent the rules of The Clean Architecture visually?

我是不是遗漏了什么？如果不是，有没有一种更正确的方式来直观地表达清洁架构的规则？

I'm asking because I am creating a diagram that shows The Clean Architecture + DDD Bounded Contexts.

我之所以问这个问题，是因为我正在创建一个展示Clean Architecture+DDD限定上下文的图表。

I'm not happy with how the DB and services bits are outside of the UseCase circle as like that it is not clear the UseCases are the public interface of the Bounded Context and that the persistence is not directly accessible from the outside.

我对数据库和服务位在UseCase循环之外的情况不满意，因为不清楚UseCase是有界上下文的公共接口，也不能从外部直接访问持久性。

Something like this solves these two issues but introduces a new one: no indication of the data access layer boundary. In fact, following the visual rules, the diagram suggests that everything in the Bounded Context can directly access the persistence.

类似这样的东西解决了这两个问题，但引入了一个新的问题：没有数据访问层边界的指示。事实上，遵循可视规则，该图表明有界上下文中的所有内容都可以直接访问持久化。

I believe I am running into the same problem that causes the Gateways to be "misplaced" in the original diagram and am looking for a way around that.

我相信我遇到了同样的问题，导致Gateways在原始图表中“错位”，正在寻找解决方法。

优秀答案推荐

The diagram shows where the implementations reside, not the interfaces. The gateway interfaces reside with the use cases.

该图显示了实现驻留的位置，而不是接口。网关接口驻留在用例中。

The diagram is a more elaborate version of Alistair Cockburn's Hexagonal Architecture, which is a lot more precise about the use of adapters, especially in respect to CDI.

该图是Alistair Cockburn的六边形体系结构的一个更精细的版本，它对适配器的使用要精确得多，特别是在CDI方面。

Essentially, the idea is to turn dependencies inward: Use Cases may depend upon Entities (i.e., import domain related packages and use domain data types; Cockburn does not describe these as separate circles, but rather as "the application"). Adapters on the left may call Use Cases (i.e., execute or abort them, e.g. using the Command pattern), while Use Cases in turn may call interfaces (such as service or repository facades, which are implemented by Adapters on the right), using the principle of Dependency Inversion to preserve the inbound direction.

本质上，这个想法是将依赖关系转向内部：用例可能依赖于实体(即，导入与域相关的包并使用域数据类型；Cockburn没有将它们描述为单独的圆，而是将其描述为“应用程序”)。左侧的适配器可以调用用例(即，执行或中止它们，例如使用命令模式)，而用例反过来可以调用接口(例如，由右侧的适配器实现的服务或存储库外观)，使用依赖关系反转的原则来保持入站方向。

If you're confused about "left" and "right": In Cockburn's picture, the hexagon has adapters on the left (input/interaction mechanisms) and on the right (persistence, external systems, services). You may think of it as a 3-layer-architecture diagram turned 90 degrees, where the domain layer does not depend on the persistence layer, but the other way around.

如果你混淆了“左”和“右”：在Cockburn的图片中，六边形的左侧(输入/交互机制)和右侧(持久性、外部系统、服务)都有适配器。您可能会认为它是一个旋转了90度的3层体系结构图，其中域层不依赖于持久层，反之亦然。

Again, Cockburn's explanation, while perhaps a bit harder to grasp due to the unusual hexagonal image, is the more precise one, because it doesn't try to include everything and concentrates on the dependency fundamentals.

同样，科克伯恩的解释，虽然可能由于不同寻常的六角形图像而更难理解，但更准确，因为它没有试图包括一切，而是专注于依赖的基本原理。

In your BC drawing your are missing a surrounding circle outside UC. That circle is infraestructure, where you should place the Repository implementation of the Repository interface of the Domain Model. The implementation access the DB using a technology (SQL for example).

在你的BC图中，你遗漏了UC外面的一个圆圈。这个圈子就是基础设施，您应该将域模型的Repository接口的Repository实现放在其中。该实现使用一种技术(例如SQL)访问数据库。

So the circles are from inside to outside:

所以圆圈是从里到外的：

• Domain Model (entities, value objects, repositories(interfaces), etc)


• Application Layer (use cases).


• Infraestructure (UI,repositories(implementation),etc)

Dependencies points inwards and not just the next circle inside (infraestructure depends both on application layer and domain model).

依赖关系指向内部，而不仅仅是内部的下一个循环(基础架构取决于应用层和域模型)。

I use hexagonal architecture though.

不过，我使用的是六角形建筑。

The gateway interfaces must reside in the use cases layer and implemented in the interface adapters layer to ensure the dependency rule.

网关接口必须驻留在用例层中，并在接口适配器层中实现，以确保依赖规则。

  Interface Adapters Layer    || Use Cases Layer
                              ||
  +-----------------+         || <implements>    +-------------+   <uses>  +---------+
  |JDBCEntityGateway| --------++-------------->  +EntityGateway|  <------  | UseCase |
  +-----------------+         ||                 +-------------+           +---------+
                              ||

This pattern can be applied to every architectural boundary. The higher level layer defines an interface to tell what it needs and not how it is done. The lower level layer implements that interface and thus defines how it is done. Maybe that's why the layer is named interface adapters. As a result of this you can change the way of how something is done by providing another implementation. You might recognize now that this is the open-close principle.

这种模式可以应用于每一个建筑边界。更高级别的层定义了一个接口来告诉它需要什么，而不是它是如何完成的。较低级别的层实现该接口，从而定义如何实现该接口。也许这就是该层被命名为接口适配器的原因。因此，您可以通过提供另一个实现来更改某些操作的方式。你现在可能认识到这就是开合原则。

But keep in mind that the interface should be a stable abstraction of what the use case needs. Don't put implementation specific things in that interface, e.g. if you specify a find method like this List<Eintity> find(String where). Becauese the where string is a detail, perhaps a SQL or JPQL string part. You should rather introduce a EntityCriteria that describes the selection criteria in an implementation independent way.

但请记住，接口应该是用例所需内容的稳定抽象。不要将特定于实现的内容放在该接口中，例如，如果您指定了如下List Find(字符串where)这样的Find方法。因为WHERE字符串是一个细节，可能是一个SQL或JPQL字符串部分。相反，您应该引入一个EntityCriteria，它以独立于实现的方式描述选择标准。

I find this question and the discussion under it very interesting because we have a comment from the user @RobertMartin and the fact that his answer adds more confusion than clarity.

我觉得这个问题和下面的讨论非常有趣，因为我们收到了用户@RobertMartin的评论，他的答案增加了更多的困惑，而不是清晰。

For the sake of consistency, and keeping only one source of truth, I will not use interpretations of the clean architecture in other articles across the internet I will also ignore the answer under this question by the user with the name @RobertMartin that states that

为了保持一致性，并且只保留一个真理来源，我不会在互联网上的其他文章中使用对干净架构的解释，我也会忽略这个问题下@RobertMartin用户的答案，该用户声明

The diagram shows where the implementations reside, not the
interfaces. The gateway interfaces reside with the use cases.

because it also does not match everything that was written in the book "Clean Architecture: A Craftsman’s Guide to Software Structure and Design by Robert C. Martin (2017)".

因为它也不符合罗伯特·C·马丁在《清洁架构：软件结构和设计工匠指南》(2017)一书中所写的所有内容。

Taking everything above into consideration as if we had only the book I will answer the question from my point of view, my interpretation of the clean architecture that was described in the book and from my personal experience of successful use of the implementation of the "clean architecture".

考虑到以上一切，就好像我们只有这本书一样，我将从我的角度回答这个问题，从我对书中所描述的清洁建筑的理解，以及我成功地使用“清洁建筑”的个人经验。

Let's start with this:

让我们从这个开始：

...following the visual rules, Use Cases cannot use the Gateways (while
they need to) and frameworky-stuff can use them (while it should not).

You know I was thinking about the same question for a week, when I tried to implement the closest implementation of the clean architecture possible, by following the description from the book word for word, because usually, you do not notice the problem until you try to decouple layers.

您知道，当我试图通过逐字遵循书中的描述来实现尽可能接近的干净体系结构的实现时，我花了一周时间思考同样的问题，因为通常情况下，直到您尝试解耦各层，您才会注意到问题。

Let's look at some related quotes from the book, and see how it is described there:

让我们来看看这本书中的一些相关语录，看看书中是如何描述的：

A use case is a description of the way that an automated system is used.
It specifies the input to be provided by the user, the output to be
returned to the user, and the processing steps involved in producing
that output.

A use case is an object. It has one or more functions that implement
the application-specific business rules. It also has data elements
that include the input data, the output data, and the references to
the appropriate Entities with which it interacts. Entities have no
knowledge of the use cases that control them.

DATABASE GATEWAYS

Between the use case interactors and the database are the database
gateways. These gateways are polymorphic interfaces that contain
methods for every create, read, update, or delete operation that can
be performed by the application on the database. For example, if the
application needs to know the last names of all the users who logged
in yesterday, then the UserGateway interface will have a method named
getLastNamesOfUsersWhoLoggedInAfter that takes a Date as its argument
and returns a list of last names. Recall that we do not allow SQL in
the use cases layer; instead, we use gateway interfaces that have
appropriate methods. Those gateways are implemented by classes in the
database layer.

What is "Between the use case interactors and the database"? Of course "Interface adapters" layer, so the book gives us an instruction on implementing a gateway interface and now we know that it should be in the interface adapters layer and implemented in the outer frameworks and drivers layer.

什么是“用例交互角色和数据库之间”？当然是“接口适配器”层，所以这本书给了我们关于实现网关接口的说明，现在我们知道它应该在接口适配器层中，并在外部框架和驱动程序层中实现。

But how to implement Use Cases without importing gateway interfaces from the outer interface adapters layer?

但是，如何在不从外部接口适配器层导入网关接口的情况下实现用例呢？

To mitigate this issue I decided to follow a technique called "Ports and Adapters" (also known as "Hexagonal Architecture" or "Ports and Adapters Architecture"), which is an architectural pattern that can help to achieve a higher degree of separation between the inner core and the outer layers. In this pattern, the inner core defines interfaces (ports) that are implemented by the outer layers (adapters), and the dependencies flow from the inner core to the adapters, without the need for the inner core to import any specific interface from the outer layers.

为了缓解这个问题，我决定遵循一种称为“端口和适配器”(也称为“六角形体系结构”或“端口和适配器体系结构”)的技术，这是一种体系结构模式，可以帮助实现内部核心和外层之间更高程度的分离。在此模式中，内部核心定义由外层(适配器)实现的接口(端口)，依赖项从内部核心流向适配器，而不需要内部核心从外部层导入任何特定接口。

I am afraid it will be hard to describe what I mean without a clear visualization, so here's an example using the Ports and Adapters pattern in the Clean Architecture in the Flutter project:

如果没有清晰的可视化，恐怕很难描述我的意思，所以这里有一个在Flutter项目的Clean Architecture中使用Ports and Adapters模式的例子：

Application Business Rules

应用程序业务规则

Use case:

使用案例：

import 'package:entities/entities.dart';

/// [GetDogsResourceUseCase] is a class with functions that have prominent
/// positions within the architecture, and they will have names that clearly
/// describe their function.
/// From the [GetDogsResourceUseCase], it is impossible to tell whether the
/// application is delivered on the web, on a thick client, or a console,
/// or is a pure service.
abstract class GetDogsResourceUseCase {
  const GetDogsResourceUseCase();

  Stream<Resource<List<Dog>>> callAsStream([Params params]);

  Future<Resource<List<Dog>>> callAsFuture([Params params]);
}

Interface adapters

接口适配器

Use case adapter:

用例适配器：

    import 'package:dogs_app_interface_adapters/dogs_app_interface_adapters.dart';
    import 'package:dogs_app_use_cases/dogs_app_use_cases.dart';
    import 'package:entities/entities.dart';
    import 'package:injectable/injectable.dart';
    
    /// A [GetDogsResourceUseCaseAdapter] specifies the [Params]
    /// to be provided by the user, the [Resource] to be returned to the user, and
    /// the processing steps involved in producing that output [Resource].
    @Injectable(as: GetDogsResourceUseCase)
    class GetDogsResourceUseCaseAdapter implements GetDogsResourceUseCase {
      const GetDogsResourceUseCaseAdapter(this._dogsGateway);
    
      final DogsGateway _dogsGateway;
    
      @override
      Stream<Resource<List<Dog>>> callAsStream([
        Params input = const Params(),
      ]) {
    //TODO: implement
    // step 1
    //_paramsGateway.getSavedDogsAsStream,
    // step 2
    //_dogsGateway.requestDogs,
    // step 3
    //_dogsGateway.saveDogs,
}
    
      @override
      Future<Resource<List<Dog>>> callAsFuture([
        Params input = const Params(),
      ]) {
    //TODO: implement
    // step 1
    //_dogsGateway.getSavedDogsAsFuture,
    // step 2
    //_dogsGateway.requestDogs,
    // step 3
    //_dogsGateway.saveDogs,
}

Gateway:

网关：

import 'package:entities/entities.dart';

abstract class DogsGateway {
  Future<List<Dog>> requestDogs([
    Params params = const Params(),
  ]);

  Stream<List<Dog>> getSavedDogsAsStream([
    Params params = const Params(),
  ]);

  Future<List<Dog>> getSavedDogsAsFuture([
    Params params = const Params(),
  ]);

  Future<void> saveDogs(List<Dog> dogs);
}

Frameworkds & Drivers

Frameworkds和驱动程序

Gateway implementation:

网关实施：

@Injectable(as: DogsGateway)
class DogsGatewayImpl implements DogsGateway {
  const DogsGatewayImpl(this._restClient, this._dogsDao);

  final RestClient _restClient;
  final DogsDao _dogsDao;

  @override
  Stream<List<Dog>> getSavedDogsAsStream([
    Params params = const Params(),
  ]) {
     //TODO: implement
     //_dogsDao.streamDogs
  }

  @override
  Future<List<Dog>> getSavedDogsAsFuture([
    Params params = const Params(),
  ]) {
    //TODO: implement
    //_dogsDao.getDogs
  }

  @override
  Future<List<Dog>> requestDogs([
    Params params = const Params(),
  ]) {
      //TODO: implement
      //_getDogsResponse(params)
  }

  @override
  Future<void> saveDogs(List<Dog> dogs) {
    // TODO: Save remote dogs in a local database
    //_dogsDao.updateDogs
  }

As you can see I achieved implementation of the same diagram that was presented in the book, without violating the dependency rules.

正如您所看到的，我实现了本书中提供的相同图表的实现，而不违反依赖关系规则。

Let's move to your next question:

让我们进入您的下一个问题：

Am I missing something?

I am afraid that either the book missing something or the diagram missing something and since I am writing this answer 6 years after publishing the book, and Robert C. Martin has not published an edited version of the "Clean Architecture" yet, we will have to use our imagination to think about what is best for our project and how it will better fit our needs creating our own interpretation of the clean architecutre.

我担心这本书或图表遗漏了一些东西，由于我是在这本书出版6年后才写下这个答案的，而且罗伯特·C·马丁还没有出版《清洁建筑》的编辑版本，我们将不得不用我们的想象力来思考什么对我们的项目最好，以及它如何更好地满足我们的需求，创造我们自己的清洁建筑解释。

And your last question:

最后一个问题是：

And if not, is there a more correct way to represent the rules of The
Clean Architecture visually?

As a matter of fact, there is. I ended up representing the diagram more correctly, at least in a way that has practical implementation and proof of concept that it can be implemented in a real project, eliminating confusion and adding <i> sign where the object represents an abstract interface.

事实上，是有的。我最终更正确地表示了图表，至少以一种具有实际实现和概念证明的方式，证明它可以在真实的项目中实现，消除了混淆，并在对象表示抽象接口的地方添加了符号。