架构（Architect）一词，起源于建筑，建筑师和架构师的英文翻译都是 Architect。在建筑设计中，非常强调一个边界感，比如篱笆圈起了整屋的边界、玄关划分了室内和室外的边界，房间的布局构建了娱乐休息和工作的边界。在软件架构中，边界感同样十分重要。好的架构和坏的架构，相当大的比例就体现在这个边界感上的区别。

架构的边界感，可以包含在三个层次中：顶层设计、模块间以及代码内。

顶层设计的边界

首先，在架构的整体规划和顶层设计中，需要考虑架构的边界。这里的边界，主要有两层的含义：

1. 软件系统需要有一个明确的定位，一个 slogan。我们将要创造是一个什么东西，做什么用，是什么不是什么，应该涵盖什么不应该涵盖什么。

2. 在系统实现的过程中，严格的遵守边界，抑制住内心的冲动，不要将和定位不符的功能纳入进来。

这个原则适用于应用软件也适用于基础组件。我们来分别阐述。

对于应用软件，边界感主要体现在功能的取舍上：明确应用系统定位的前提下，区分属于和不属于系统的能力，做出合理的取舍。

例如，我们要建设一个外汇交易系统，明确系统的职责是为用户提供外汇交易的能力。那么，询价、定价、交易、交割、短款管理等，就很明显的属于系统的范畴。相反，用户资金管理、核算、和渠道的交互等，属于依赖的能力，但不属于本系统的范畴，应该交给其他的系统来实现。

对于基础组件，同样需要明确本技术组件的定位和涵盖的范畴。对于基础组件，功能的取舍会体现在两个方面：

1. 和应用软件一样，聚焦于本领域，不要去涉及其他技术组件需要提供的服务。比如，我们设计一个消息中间件，首先可以明确职责范围是消息的可靠接收、存储、发送，以及扩展的发布和订阅能力。那么，什么定时消息、邮件短信通知之类的功能就很明显不应该应收尽收。这些应该交给定时任务框架、沟通服务去实施。应用层编排产品功能的时候，可以同时依赖消息中间件、定时任务框架和沟通服务。

2. 不要侵入业务概念。基础组件聚焦于基础的技术特性，不应该去理解上层的业务。比如，我们可以实现优先级任务，但是不应该理解业务场景之间的优先级排序，不应该理解同币种需要聚合处理。可以将这些抽象为优先级和分组，具体业务概念和基础组件概念的映射，应该交由上层的业务系统来完成。一些基础组件团队同学说的不理解业务，在架构层面，反而不是一件坏事，是一个正确的“借口”。

应用（模块）的边界

在微服务架构下，一个系统会由多个应用构成；在单体架构下，一个应用系统会被划分成多个模块。不管是哪种架构，在边界感上都是一致的，在应用和应用之间，或者模块和模块之间，需要有明确的边界划分。

应用系统的边界，可以体现在四个层面：

1. 服务的边界：一个应用对外的服务，应该涵盖什么样功能，应该 cover 多少场景，应该包含哪些字段（信息）。

2. 模型的外部边界：一个应用的模型，应该包括哪些实体，应该维护什么样的关系，外部模型和内部模型的映射应该在界内还是界外。

3. 模型的内部边界：如何切分实体，实体应该包含哪些字段（属性）。

4. 代码逻辑的边界：代码如何分层。

服务的边界，在 Restful 成为主流的背景下，基本恒等于模型的外部边界。

代码逻辑的边界，无论是 DDD，还是 MVC/MVVM，还是 sofa 框架，已经都切分的比较清楚了，在架构师内部基本有一定的共识。

所以这里主要聊一下模型的内外边界问题。

首先，模型的外部边界，就是应用的功能边界，这个和系统的边界是一样的，follow 应用的定位。

同时，内外模型之间的映射，一般放在使用方。这个逻辑很简单，使用方是发散的，服务提供方是收敛的，按照开闭原则，应该放在发散的一方。

对于模型的内部边界，就没有这么明显，比较依赖架构师的业务领域能力和架构经验。除了通过领域概念来切分模型边界之外，在实践过程中，我们总结了几个普遍的原则可以一起探讨一下：

• 数量原则：如果两个模型之间不是一一对应的关系，比如借款和还款、存单和利息，一般会拆分成两个模型。

• 动静原则：如果两个模型的变化频率不同，比如订单和操作日志，一般会拆分成两个模型。

• 时差原则：如果两个模型创建或者消亡的时间点不同，比如正向下单和反向退款，一般可以考虑拆分成两个模型。

• 读写原则：如果两个模型在读和写比率、频率、时间上有比较大的差别，比如用户基本信息和用户认证信息，在分布式系统下，可以考虑拆分成两个模型。

代码的边界

代码的边界，指类、方法之间的边界。这一部分属于比较微观的架构边界，相对来说影响面和优先级也会低一点。

对于类的边界，很显然需要 follow 模型的边界，而且需要将模型的属性和方法聚合，贫血模型和属性外露同样不可取。

对于方法的边界，无非就是功能的聚焦。代码的结构应该同时具备流变和层次的特性：代码从阅读上应该像读自然语言一样顺畅，同一层次应该看到同等级别的方法，更细的力度应该封装在方法的内部逻辑中。

架构师的超越边界

前面充分阐述了架构的边界，那么对于架构的创造者架构师，我们是不是也应该 follow 这个边界，比如基础组件的架构就不用理解业务，各个业务系统的架构师也不需要跨过边界去接触其他的业务领域呢？

答案是否定的，和架构的边界感不同，架构师需要一种超越边界的感觉。这里面的道理也比较容易理解，只有从上帝视角，从边界以外去看，才能看清楚全貌，才能明确边界的划分是否合理。

对于架构师的超边界感，可以体现在三个方面：

1. 架构师的跨越领域能力：基础平台架构师需要熟悉业务，每个领域的应用架构师需要了解周边领域的概念，全局架构师需要去接触相关行业的知识。

2. 架构师的超越岗位能力：架构师对于业务的熟悉，不应该仅仅局限于应用系统和代码逻辑，需要从产业政策、业务逻辑、产品概念一路看上去，需要间接具备一定的 BD、PD 甚至财务、法务的基本能力。

3. 架构师的穿越时空能力：过去成功的架构师不一定能适应未来的需要，架构能力、技术感觉和业务领域知识需要持续的升级。