架构演进

现代架构模式的演进有一条清晰的主线：把业务逻辑放在中心，把技术细节推到外围。围绕这条主线，架构流派从"分层"逐步走向"内外"，核心问题始终是同一个——如何让业务核心不被技术实现污染。

六边形架构

传统的分层架构把系统分成上下层，但六边形架构认为系统不该分上下，而该分内外：业务逻辑（Domain）居于内部，通过"端口"（Ports）与外界通信，而数据库、HTTP 接口、消息队列都是外接的"适配器"（Adapters）。换一个数据库就像换一个插头，不影响核心逻辑。

这种"内外"切分的好处是业务逻辑完全不依赖技术实现，技术栈迁移或新增访问渠道时，核心代码无需改动。这与容器作为治理边界的思路是一致的：业务核心是边界内部被精心治理的资源，技术细节是边界外可替换的适配器。

整洁架构

整洁架构是六边形思想的进一步系统化，核心是一条依赖规则：依赖只能从外向内指向。最内层的实体（Entities）最稳定、最抽象，最外层的框架（Frameworks）最易变；每一层都只能依赖比自己更内、更稳定的层。

这条规则把"稳定性"和"位置"绑死：越往内越稳定越抽象，越往外越易变越具体。于是组件耦合中的 SDP 和 SAP 在这里被具象成了一种空间布局——把稳定抽象的东西放进核心，把易变具体的东西留在边缘。

DDD：领域驱动设计

如果说 SOLID 教我们写好一个类，DDD 教我们设计一个复杂的业务系统。它有两件法宝。

统一语言（Ubiquitous Language）要求程序员和业务方用同一套词汇交流，代码里的类名要和业务名词对齐。这种对齐不是简单的命名映射，而是对业务领域的深入建模——当业务方说"退款"而代码里只有 RefundOrder 时，模型和现实之间的缝隙就已经在制造 bug 了。

限界上下文（Bounded Context）是 DDD 的核心。它强调明确边界：同一个"商品"，在仓库系统里关注库存，在营销系统里关注价格。DDD 用边界来隔离同一个概念在不同上下文里的不同含义，这与作用域划分的思路高度契合。

边界即最难

回看这些流派，技术细节千差万别，但内核都是同一件事：划定边界。架构设计最难的部分从来不是写代码，而是判断这条边界该划在哪里——划得太大，系统臃肿难改；划得太碎，协作成本爆炸。所有的架构原则，本质上都是在回答"什么该被关进同一条边界里"。