架构的尖叫

Screaming Architecture
架构的尖叫

    uncle bob
    30 Sep 2011
    Architecture


Imagine that you are looking at the blueprints of a building. This document, prepared by an architect, tells you the plans for the building. What do these plans tell you?
想象你正在看一栋建筑的蓝图，这份由架构师准备的文档告诉了你整个建筑的规划。那么这些规划会告诉你什么呢？

If the plans you are looking at are for a single family residence, then you’ll likely see a front entrance, a foyer leading to a living room and perhaps a dining room. There’ll likely be a kitchen a short distance away, close to the dining room. Perhaps a dinette area next to the kitchen, and probably a family room close to that. As you looked at those plans, there’d be no question that you were looking at a house. The architecture would scream: house.

如果你看到的规划是一个单一的家庭住宅，那么你可能会看到一个前门，一个通向客厅的休息室，也许是一个饭厅。可能还有一个离餐厅很近的厨房。也许厨房旁边可能是餐桌，家庭室可能很近。当你看那些规划时，毫无疑问可以确认你是在看房子。架构会尖叫：房子。

Or if you were looking at the architecture of a library, you’d likely see a grand entrance, an area for check-in-out clerks, reading areas, small conference rooms, and gallery after gallery capable of holding bookshelves for all the books in the library. That architecture would scream: Library.

或者你正在看一座图书馆的规划。你可能会看到一个大入口，一个供登记的区域，阅读区，小会议室，以及一排排的放满书的书架。那个建筑会尖叫：图书馆。

So what does the architecture of your application scream? When you look at the top level directory structure, and the source files in the highest level package; do they scream: Health Care System, or Accounting System, or Inventory Management System? Or do they scream: Rails, or Spring/Hibernate, or ASP?

那么你的应用程序的架构会尖叫什么呢？当您查看顶层目录结构和高层包中的源文件时，它们会尖叫：医疗系统、会计系统或库存管理系统吗？或者他们尖叫：Rails，或Spring，Hibernate，或者ASP？

The Theme of an Architecture
架构的主题

Go back and read Ivar Jacobson’s seminal work on software architecture: Object Oriented Software Engineering. Notice the subtitle of the book: A use case driven approach. In this book Ivar makes the point that software architectures are structures that support the use cases of the system. Just as the plans for a house or a library scream about the use cases of those buildings, so should the architecture of a software application scream about the use cases of the application.
回溯并翻阅Jacobson的软件架构方面的开创性工作：面向对象的软件工程。注意书的副标题：用例驱动的方法。在这本书中，Ivar提出软件架构是指能够支撑系统所有用例的结构的观点。正如房屋或图书馆的规划对这些建筑物的用例尖叫一样，软件应用程序的架构也会对应用程序的用例进行尖叫。

Architectures are not (or should not) be about frameworks. Architectures should not be supplied by frameworks. Frameworks are tools to be used, not architectures to be conformed to. If your architecture is based on frameworks, then it cannot be based on your use cases.

架构不是（或者不应该是）关于框架的。架构不应该通过框架来提供。框架仅仅是使用的工具，而不是被确认的架构。如果你的架构是基于框架的，那么它就没法基于你的用例。

The Purpose of an Architecture

架构的目的

The reason that good architectures are centered around use-cases is so that architects can safely describe the structures that support those use-cases without committing to frameworks, tools, and environment. Again, consider the plans for a house. The first concern of the architect is to make sure that the house is usable, it is not to ensure that the house is made of bricks. Indeed, the architect takes pains to ensure that the homeowner can decide about bricks, stone, or cedar later, after the plans ensure that the use cases are met.
好的架构聚焦于用例的原因是，如此一来，架构就可以安全地描述支撑用户的结构而不用关心框架，工具和环境。再说一遍，就像房屋的规划一样。架构第一个要关心的，是确保房子是可用的，而不是房子是由砖头垒成的。事实上，架构要在努力确保房主的用例可以满足的前提下，再在稍后的规划中做砖块、石头或雪松的决定。

A good software architecture allows decisions about frameworks, databases, web-servers, and other environmental issues and tools, to be deferred and delayed. A good architecture makes it unnecessary to decide on Rails, or Spring, or Hibernate, or Tomcat or MySql, until much later in the project. A good architecture makes it easy to change your mind about those decisions too. A good architecture emphasizes the use-cases and decouples them from peripheral concerns.

一个好的软件架构允许框架、数据库、Web服务器以及其他环境问题和工具的决定可以被推迟和延迟。一个好的架构使得项目不必取决于Rails、Spring、Hibernate、Tomcat或MySQL，这些因素可以在项目后期阶段解决。一个好的架构也能很容易地改变这些决策。一个好的架构强调用例，以及用例和外围的解耦。

But what about the Web?

但Web又是什么情况呢？

Is the web an architecture? Does the fact that your system is delivered on the web dictate the architecture of your system? Of course not! The Web is a delivery mechanism, and your application architecture should treat it as such. The fact that your application is delivered over the web is a detail and should not dominate your system structure. Indeed, the fact that your application is delivered over the web is something you should defer. Your system architecture should be as ignorant as possible about how it is to be delivered. You should be able to deliver it as a console app, or a web app, or a thick client app, or even a web service app, without undue complication or change to the fundamental architecture.

Web是个架构吗？允许在web上交付应用会决定你系统的架构吗？当然不是。web只是一个交付的机制，你的应用架构也应该这样对待web。事实上，你的应用是否在web上交付是个很细节的问题，并且不应支配你的系统结构，更进一步，你的应用是否在web上交付应该是一个延迟决策。你的系统架构应该忽略掉它怎么交付。你应该能够通过诸如控制台应用，web应用或者瘦客户端，甚至是web service应用等来交付，而不会对基础架构造成不必要的复杂性或更改。

Frameworks are tools, not ways of life.
框架是工具而不是生活方式

Frameworks can be very powerful and very useful. Framework authors often believe in their frameworks. The examples they write for how to use their frameworks are told from the point of view of a true believer. Other authors who write about the framework also tend to be disciples of the true belief. They show you the way to use the framework. Often it is an all-encompassing, all-pervading, let-the-framework-do-everything position. This is not the position you want to take.

框架是威力强大而且用途颇广的。框架的作者经常迷信于他们的杰作。他们往往从一个虔诚信徒的角度来编写如何使用他们的框架的demo。写这个框架的其他作者也往往是虔诚信徒的门徒。他们向你展示如何使用框架。通常来说，它是包罗万象的，无孔不入的，它可以做一切事情。这不是你想要的角度。

Look at each framework with a jaded eye. View it skeptically. Yes, it might help, but at what cost. How should I use it, and how should I protect myself from it. How can I preserve the use-case emphasis of my architecture? How can I prevent the framework from taking over that architecture.

用一只疲惫的眼看看每个框架。用质疑的眼光看看它。是的，它可能是有帮助的，但要知道它的代价。我应该怎么用它，我应该怎么和它保持距离？我怎么保护我的架构中的重点用例？我怎么阻止框架渗透到架构中？

Testable Architectures.
可测试的架构

If you system architecture is all about the use cases, and if you have kept your frameworks at arms-length. Then you should be able to unit-test all those use cases without any of the frameworks in place. You shouldn’t need the web server running in order to run your tests. You shouldn’t need the database connected in order to run your tests. Your business objects should be plain old objects that have no dependencies on frameworks or databases or other complications. Your use case objects should coordinate your business objects. And all of them together should be testable in-situ, without any of the complications of frameworks.

如果你的系统架构全是关于用例的，并且如果你已经和你的框架保持一臂距离，那么你应该不使用任何框架就能够单元测试所有的用例。你不应该需要web服务器去跑你的测试，你不应该需要数据库连接去跑你的测试。你的业务对象应该不依赖框架或者数据库或者其他并发体。你的用例对象应该和你的业务对象协同。所有的业务应该是独立可测试的，不依赖于任何的框架。

Conclusion
结论

Your architectures should tell readers about the system, not about the frameworks you used in your system. If you are building a health-care system, then when new programmers look at the source repository, their first impression should be: “Oh, this is a heath-care system”. Those new programmers should be able to learn all the use cases of the system, and still not know how the system is delivered. They may come to you and say: “We see some things that look sorta like models, but where are the views and controllers”, and you should say: “Oh, those are details that needn’t concern you at the moment, we’ll show them to you later.”

你的架构应该把系统告诉给读者，而不是你的系统使用的框架。如果你正设计一个医疗系统，当新手看到源码结构的时候，他们的第一印象应该是：“喔，这是一个医疗系统。”那些新手应该能够从系统中学到所有的用例，但可能还不清楚系统是如何交付的。他们来到你面前，说：“我们看到了一些东西，看起来有点像模型，但视图和控制器在哪里？”你应该说：“哦，这些都是细节，当前你们不用关心，我们以后会告诉你们。”