The Onion Architecture（洋葱架构） part3

In my previous installments, I described what has become my approach to defining the architecture for an application.  Based on feedback, I've modified my diagrams a bit to reduce ambiguity and emphasize key points.  The goal of part 3 of this series is to compare and contrast the Onion Architecture with traditional layered architecture.  I will flatten the Onion Architecture to see what it looks like compared to traditional layered architecture, and I will force the layered architecture into an onion.  Whereas the shape can be either, the structure of the actual application is radically different from what is commonly known and accepted.  I'll define four tenets of Onion Architecture at the end.

在前面的部分中，我描述了如何定义应用程序的体系结构的方法。根据反馈，我已经修改了我的图，以减少歧义和强调关键点。本系列第3部分的目标是比较和对比洋葱架构与传统分层架构。我将对洋葱架构进行扁平化，看看它与传统分层架构相比是什么样子，我将把分层的架构变成一个洋葱。虽然形状可以类似，但实际应用的结构与通常所知道和接受的是根本不同的。最后，我将定义洋葱架构的四个原则。

I must stress again:  I am not claiming any breakthroughs in technology or technique.  I have learned from other industry thought leaders like Martin Fowler, Ward Cunningham, Kent Beck, Michael Feathers and others (especially those I've had the privilege to work with here in Austin, TX).  I'm putting forth the Onion Architecture as an architectural pattern by which we can communicate this radically different architectural approach.  Not "radically different as in new".  Different as in not mainstream.

我必须再次强调：我并没有宣称任何技术或技术方面的突破。我从其他业界引领者那里学到了很多东西，如Martin Fowler, Ward Cunningham, Kent Beck, Michael Feathers 和其他人（尤其是那些我有幸在TX奥斯丁工作的人）。我把洋葱架构作为一种架构模式，通过它我们可以传达这种完全不同的架构方法。不是“与新的完全不同”，是与主流不同。

Let's review.  Traditional layered architecture can look somewhat like the diagram depicted on the right.  Each layer communicates with the layer below it.  The UI talks to business logic, but it does not talk directly to data access, WCF, etc.  The layering approach does call out the need to keep certain categories of code out of the UI.  The big downfall is that business logic ends up coupled to infrastructure concerns.  Data Access, I/O, and Web Services are all infrastructure.  Infrastructure is any code that is a commodity and does not give your application a competitive advantage.  This code is most likely to change frequently as the application goes through years of maintenance.  Web services are still fairly new, and the first version in .Net, ASMX, is already deprecated in favor of WCF.  We can be assured that WCF's days are numbered as well, so it is foolish to tightly couple the business logic to WCF.  Data access changes every two years or so, so we definitely don't want to be tightly coupled to it.  For long-life, we would want our business logic to be independent of these infrastructure concerns so that as infrastructure changes, the business logic doesn't have to.

让我们回顾一下。传统分层架构看起来有点像右边描述的图表。每层与下面的层通信。UI与业务逻辑交互，但它不直接与数据访问、WCF等进行交互。分层方法确实需要将某些类别的代码保留在UI外。最大的失败是业务逻辑最终与基础设施相关联。数据访问、I/O和Web服务都是基础设施。基础设施是商业化的代码，它不会给你的应用带来竞争优势。当应用程序经过多年维护时，这种代码最有可能频繁更改。Web服务仍然是相当新的，相对于第一个版本的.NET，ASMX已经被WCF弃用。我们可以确认，WCF也时日无多，所以将业务逻辑紧密耦合到WCF是愚蠢的。数据访问每两年更改一次，所以我们绝对不想紧耦合它。对于长生命周期而言，我们希望业务逻辑独立于这些基础设施关注点，以便基础设施变化时，业务逻辑不必变化。

Let's review Onion Architecture.  The object model is in the center with supporting business logic around it.  The direction of coupling is toward the center.  The big difference is that any outer layer can directly call any inner layer.   With traditionally layered architecture, a layer can only call the layer directly beneath it.  This is one of the key points that makes Onion Architecture different from traditional layered architecture.  Infrastructure is pushed out to the edges where no business logic code couples to it.  The code that interacts with the database will implement interfaces in the application core.  The application core is coupled to those interfaces but not the actual data access code.  In this way, we can change code in any outer layer without affecting the application core.  We include tests because any long-lived application needs tests.  Tests sit at the outskirts because the application core doesn't couple to them, but the tests are coupled to the application core.  We could also have another layer of tests around the entire outside when we test the UI and infrastructure code.

让我们回顾一下洋葱建筑。对象模型位于中心，业务逻辑环绕于它。耦合的方向是朝向中心的。最大的区别在于，任何外层都可以直接调用任何内层。按照传统分层架构，一个层只能直接调用它下面的层。这是洋葱架构不同于传统分层架构的关键之一。基础设施被推到没有业务逻辑代码耦合的边缘。与数据库交互的代码实现应用内核中的接口。应用内核与这些接口耦合，而不是实际的数据访问代码。通过这种方式，我们可以在不影响应用内核的情况下更改任何外层的代码。我们将测试包含在内，因为任何长生命周期的应用都需要测试。测试位于外围，因为应用内核不耦合它们，但测试耦合到应用内核。当我们测试UI和基础结构代码时，我们还可以在整个外部进行另一层测试。

This approach to application architecture ensures that the application core doesn't have to change as:  the UI changes, data access changes, web service and messaging infrastructure changes, I/O techniques change.

这种应用程序架构的方法确保应用内核当如下因素更改时不必更改：UI更改、数据访问更改、Web服务和消息基础结构更改、I/O技术更改。

To the right, I have created a diagram which attempts to show what Onion Architecture would look like when represented as a traditionally layered architecture.  The big difference is that Data Access is a top layer along with UI, I/O, etc.  Another key difference is that the layers above can use any layer beneath them, not just the layer immediately beneath.  Also, business logic is coupled to the object model but not to infrastructure.

在右边，我创建了一个图，尝试展示为传统分层架构时，洋葱架构会是什么样子。最大的不同在于数据访问是一个顶层，同时还有UI、I/O等。另一个关键的区别是上面的层可以使用它们下面的任何层，而不仅仅是下面一层。此外，业务逻辑与对象模型耦合，但不与基础设施耦合。

To the left here I have attempted to represent traditionally layered architecture using concentric circles.  I have used black lines around the layers to denote that each outer layer only talks to the layer immediately toward the center.  The big kicker here is that we clearly see the application is built around data access and other infrastructure.  Because the application has this coupling, when data access, web services, etc. change, the business logic layer will have to change.  The world view difference is how to handle infrastructure.  Traditional layered architecture couples directly to it.  Onion Architecture pushes it off to the side and defines abstractions (interfaces) to depend on.  Then the infrastructure code also depends on these abstractions (interfaces).  Depending on abstractions is an old principle, but the Onion Architecture puts that concepts right up front. 

在左边，我试图用同心圆表示传统分层架构。我在图层周围使用黑色线条表示每个外层只与内部图层直接交互。这里的一个大问题是，我们清楚地看到应用程序是围绕数据访问和其他基础设施构建的。因为应用程序具有这种耦合性，当数据访问、Web服务等发生变化时，业务逻辑层将不得不改变。世界观的差异在于如何处理基础设施。传统分层架构直接耦合到它。洋葱架构将它推到一边并通过定义抽象（接口）进行依赖。然后基础结构代码也依赖于这些抽象（接口）。而后基础结构代码也依赖于这些抽象（接口）。依赖抽象是一个古老的原则，但是洋葱架构把这些概念摆在了前面。