北京
一个软件系统不管长到多大，它总有一条边界。这条边界把系统内部的东西和外部的东西分开。把大系统拆成多个组件能带来不少好处，但怎么拆、拆在哪，考验的是开发者的判断力。
经验在这类决策里是最好的老师。不过，也有一些策略能帮上忙。
边界到底在管什么
一条好的软件边界，会把应用的职责、规则，以及应用这些规则所需的细节，收拢在同一处。边界之外的部分想和边界之内通信，只能通过一条清晰的通路。
这就意味着，划定边界这项技能，要求你先想清楚哪些职责应该被归到一起，以及它们之间应该存在哪些依赖关系。
换句话说，边界不是画一条线那么简单，它是一次关于"谁和谁该待在一起"的取舍。职责分错了组，依赖就会变得混乱；依赖理不清，边界也就形同虚设。
拆分的收益与代价
把大型系统拆成多个组件，好处是显而易见的。但决定系统应该如何被划分，需要技能，也需要理解。这两样东西不会凭空出现。
经验之所以是最好的老师，是因为边界决策往往没有标准答案。同一个系统，不同的拆法可能都说得通，但长期维护下来的成本差别很大。踩过坑的人，才知道哪条线不该画。
策略能做的，是给这种判断提供一些抓手。它们不能替你做决定，但能让你在做决定时少一些盲目。
先想职责，再想依赖
回到那条边界本身。它要守住的是职责、规则和细节这三样东西的完整性。边界外的东西只能通过清晰通路进来，这条通路就是依赖的入口。
所以划边界时的顺序大致是：
- 先判断哪些职责应该被归到一起
- 再判断这些职责之间应该存在哪些依赖
- 最后确认外部只能通过一条清晰通路访问边界内部
这个顺序反过来做，很容易先画出漂亮的架构图，却发现职责被切得七零八落，依赖关系绕成一团。
边界这件事，说到底是把复杂系统的复杂度关进一个个可控的盒子里。盒子怎么分，决定了你以后是打开一个盒子就能改完，还是得同时掀开五个盒子。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
