边界的作用是推迟不成熟决策，最耗人力的是过早决策导致的耦合

软件架构设计本质上是一门划分边界的艺术：边界把软件切成不同元素，用来约束边界两侧的依赖关系，有些边界在项目初期、甚至写代码之前就该划好，目的是尽量把某些决策推迟，并确保它们不干扰核心业务逻辑。架构师追求的目标是最小化构建维护系统所需的人力资源，而一个系统里最消耗人力的东西正是耦合——尤其是那些过早做出的、不成熟决策所导致的耦合。判定一个决策是否”过早且不成熟”的标准很清晰：只要这个决策与系统的业务需求（用例）无关，就属于这一类——采用哪个框架、哪种数据库、哪个Web服务器、哪些工具库、要不要依赖注入，都是这种辅助性、本该被推迟的细节决策。在设计良好的架构里，这些细节决策不应该被系统核心依赖，架构师的职责是尽可能推迟它们，并把推迟本身带来的影响降到最低。发散：这条原则和[[保持可选项策略与细节脱钩让实现决策尽可能推迟]]是同一个思路的不同表述——只不过这一章要具体回答”怎么做”：用边界这个工具，把与业务无关的决策从核心业务逻辑里物理地隔离出去。