尖叫的架构，指的是你一看到整体设计，就知道它的作用是什么。
例如，一个住宅的设计图纸，我们一看到每个房间的作用，应该不会怀疑这是一个住宅。几乎整个建筑设计都在尖叫着告诉你：这是一个家。
我们的软件架构设计，也应该如此。当我们查看顶层结构目录，以及源代码时，它们应当尖叫的告诉你这是什么业务系统，而不是告诉你这是Rails，Spring，ASP这样的技术名词。
架构设计的主题
作者这里推荐了一本书，《Object Oriented SofwareEngineering》作者是Ivar Jacobson，他是UML之父。
在这本书中，Jacobson提出了一个观点：软件的系统架构，应该为该系统的用例，提供支持。就像住宅和图书馆的建筑计划一样，都在非常明显的凸显这些建筑的作用和使用说明。
软件系统的架构设计图，也应该非常明确的凸显，该应用程序，会有哪些用例（该应用程序，可以被怎样使用）。
架构设计不应该与框架相关，这件事不应该是基于框架来完成的。框架只是一个工具，而不是架构所规范的内容。如果基于框架设计，他就不能基于我们的用例来设计了。
架构设计的核心目标
一个良好的架构设计应该围绕着用例来展开，这样做可以脱离框架，工具，以及使用环境的情况下完整的描述用例。
就好像一个住宅设计的首要目标，应当是满足住宅的使用需求，而不是确保一定要使用某种建筑材料。软件工程应当花费更多的精力首先满足用例需要的情况，在此基础上，再尽可能地允许用户能自由地选择建筑材料。
而且，良好的架构，应该尽可能地允许用户推迟或延迟采用什么框架，数据库，Web服务以及其他工具。框架应该是一个可选项，良好的架构设计应该允许项目后期再决定是否采用某种工具。
总之，良好的架构设计应该只关注用例，并能将他们与其他周边因素隔离。
那 Web 呢
Web究竟是不是一种架构。很显然它不是，它只是一种交付手段，一种IO设备，这就是它在架构设计中的角色。它不应该主导整个项目设计，它本身就应该是一个被推迟和延后的决策。我们的系统，在不更改基础架构设计的情况下，应当做到可以很方便的将应用程序交付成命令行，Web，客户端等。
框架是工具而不是生活信条
框架可以是非常强大，非常有用的，而很多作者也会告诉应当如何使用这种框架，他们会告诉你某个框架能包揽一切，超越一切，解决一切。他们是框架宗教狂热份子。
但这不应该成为你的观点。
我们一定要带着怀疑的态度审视每一个框架。我们需要仔细地考虑如何保持对系统用例的关注，避免框架主导我们的架构设计。
可测试的架构
如果系统架构的所有设计，都是围绕着用例来展开的，并且在使用框架的问题上保持谨慎，那么我们就可以做到在不依赖任何框架的情况下，对这些用例进行单元测试。
另外在运行测试的使用不应该运行Web服务，也不应该需要连接数据库。（因为这些都是可以被延后的决策，所以我们可以以此来倒推我们的核心架构）。我们的测试应该只是一个简单的业务实体对象，不与任何框架，数据库相依赖。
总而言之，我们应该通过用例对象来调度业务实体对象，确保所有的测试都不需要依赖框架。
我自己的理解：假设有一个负责下单的实体对象。我们可能会想这怎么可能不与数据库相关联呢？其实这样可以倒推，如果要做到不相关联，那么就要确保核心的实体对象，不与数据库发生关联，它只接收数据，输出数据。那么查询库存，和下单，就应该是调用层的事情了。
那调用层既然要判断库存和扣库存，应该也是属于核心
逻辑之一，它负责组装策略，那它的单元测试又如何不与数据库发生关系呢？往上一层一层剥，总有那么一层，是要与数据库发生关系的吧（下一章节会讲到具体分层，与数据库打交道的在接口适配器层）？要做到这样，倒推出来，我们可以在对象和函数设计时，引入注入概念，比如判断库存，通常是在函数中查询库存，我们可以直接在函数设计时，传入库存数量和购买商品信息。这样测试时，我们可以直接传入参数，让其函数不需要自己查。
本章小结
系统架构，应该着重于系统本身的设计，而非使用的框架。好的架构，可以让新来的程序员第一次看到源码时，就知道这是一个什么样的系统。新来的程序员应该先了解该系统的用例，而非交互方式。
