答案

在经典的系统分析中，正确界定设计系统的边界非常重要——哪些功能在系统内部实现，哪些交给外部服务，如何与它们进行集成。在大型项目中，这个阶段对简化架构和最小化风险至关重要。

关键特征：

• 系统边界根据 业务功能、职责区、数据组成 来确定。
• 需要定期 分析现有服务和接口，以避免重复。
• 重要的是处理 集成场景、格式和入口/出口点。

问题的历史

在70年代和80年代，分析大型系统时显而易见，选择不当的边界会导致代价高昂的集成调整和架构混乱。

问题

系统边界过宽或过窄都会使维护复杂化，增加集成数量，导致数据不一致。

解决方案

使用上下文图（Context Diagram）技术，以及服务责任矩阵（Service Responsibility Matrix）来分配功能和责任。强调业务目标，以便系统边界与公司的实际结构相符。

误导性问题。

是否总是需要追求创建的系统的最大自主性？

不，有时将部分功能委托给其他系统更有效，以避免重复。

分析师是否需在实施之前确定所有集成的数据格式？

不，这是在高层设计（high-level design）阶段进行的。详细格式将在后续与架构师和集成商共同制定。

如果同一功能在多个系统中实现，会不会很糟糕？

这会导致重复、同步成本和数据完整性丧失，因此应避免这种交叉。

常见错误和反模式

• 不处理上下文图。
• 忽视公司已有的服务。
• 在未确定业务边界的情况下，立即进入技术集成细节。

生活实例

负面案例：
在没有考虑公司结构的情况下设计系统，未明确哪些功能在内部，哪些在其他服务中。
优点： 项目设计启动迅速，资源消耗最小。 缺点： 导致许多重复的集成，数据交换不断出现问题，架构膨胀。

正面案例：
系统分析师开发了上下文图，明确了与业务和架构师的系统边界，最小化了集成交互。
优点： 透明的架构，更少的集成错误，方便维护。 缺点： 启动时需要大量准备工作，对所有相关系统的专业知识的要求。