系统由领域组成，领域又由细分领域组成……由此我们最终所讨论的、具体的、作为组成部件的领域被表达为：口包含了特定领域知识，□提供了基于上述知识的处理能力，口反馈了在领域间可理解信息的一组行为。

对于这样一组行为，我们称之为“(该子系统/领域的)接口”。请注意，我们讨论系统中的接口时，它是脱离具体语言的。我们需要这样一层抽象概念的根本原因在于：(1)将领域问题转义为一组逻辑的界面；(2)将领域间有无关系，转义为“领域对领域(调用者与被调用者)”的接口是否可达：(3)屏蔽领域内的数据性质①,迫使开发者必须通过特定的设计来解决领域间的数据问题(例如数据类型、数据依赖等)。

在这三种原因或可称为三类需求及其解决手段中，第一种和第二种是显性的，它们由接口的抽象特性决定：其一，表达为一组方法；其二，能否使用这些方法，取决于能否获得接口。

【系统的基本组织方法与原理】

第三种则是隐性的，并且也是决定系统稳定性的最主要因素。事实上在这样的背景之下，开发者能够选择的方案也相对有限，主要包括远程方法或远程对象、消息/状态、序列化、分布等。

最终，我们将提供一组接口的系统组成构件称为一个“服务”,或一个“结点”。前者是功能视角下的一个概念，后者则基于部署视角。②但总的来说，服务/结点都意味“非本地”的支持，这也可以理解为对“跨领域的需求”的支持。yipindushu.com

①这涉及数据的全部三种性质：标识、值与确定性，以及由确定性带来的分布、状态等性质。②两者除了抽象视角的不同，在实现上通常也有差异(这里的服务与结点主要分别基于Java和Erlang中的概念)。

系统与子系统之间面临的第一个问题，是系统的整体部署。系统的部署方案几乎决定或限制了大多数有关系统的决策，其中首当其冲的是数据的结构化与预结构化问题。

数据在哪里?数据的型式是什么?数据的量级、频度与粒度如何?这是系统整体部署中避无可避的三个关键问题。我们先讨论B/S架构下的数据，通常它们的大多数数据项表现为微数据，其数据粒度小、频度高、可靠性差。

频度高意味着单次处理数据的CPU占用要尽可能小，这是维持大的系统处理能力的诀窍。但如果一笔数据的结构不确定，发现数据有效性以及决策计算路径的代价就将变得极其巨大。举例来说，Java的Web应用框架大多提供“将HTTP Request转换为一个数据对象”的能力，其优势是在应用层中不需要关心数据来源与有效性。这一方面可以让应用层用类同的方式处理请求，另一方面也可以屏蔽一些框架逻辑，例如通过注解(annotation)来做数据验证。而且在第三个方面，这还可以将服务端与请求端无缝隔离，例如一个应用处理逻辑并不关心请求是来自于Web客户端，还是来自于Open API接口。

但是“将HTTP Request转换为一个数据对象”的代价极其巨大，其本质上是在服务端、在应用服务器的框架层上进行数据的预结构化。如果我们理解这一点，那么我们在Web客户端对数据格式进行预处理，并与服务器端将这一规格协商作为协议，其效果将是十分显著的。例如大多数B/S应用会面临登录验证的问题，它们需要处理大抵三类需求：□如果用户未登录，则一些客户端请求无效；□如果用户未登录，则一些客户端请求被保持，并在再次登录后提供服务；□如果用户已登录，则可以为客户端请求提供正常服务。

“登录与否”有许多种特定的验证方法，例如是否存在用户名(UserName),是否存在用户会话(Sessionld),是否存在验证数据(CertData)等。但我们这里先关注“验证数据的获取”,这在一个HTTP Request中有几种来源①: Cookie、Get Fields、Post URL和Post Data。其中Get Fields与Post URL是同类型的东西，因为“Method为Get的①在定制的HTTP客户端中，也可能将验证信息直接放在HTTP Head中，例如超星浏览器等使用HTTP协议的软件。但是这在通常的、基于浏览器的B/S应用中很难有通用性(如果非要这样做，可通过浏览器插件来实现)。