在现代AI或云项目中，我们目前处于什么阶段？通常我们已经跨过了初步的销售沟通，但尚未准备好开始构建。在这个阶段，团队虽然明确了业务目标，但仍有太多的技术细节尚不清楚。风险很高，因为架构还没有经过系统实际需求的检验。
这就是为什么工作重心转向了“探索”。探索将宽泛的想法转化为架构愿景。它定义了系统的目标形态、通往目标的途径、所需的支持团队以及实施的工作说明书。用通俗的话来说，它回答了一个简单的问题：我们究竟在构建什么样的系统，它必须满足哪些条件？
属性驱动设计（Attribute Driven Design，简称ADD）是回答这一问题最清晰的方法之一。它是一种通过从系统的重要质量和约束入手来设计软件架构的方法。与其先猜测一个结构并希望它稍后能适配，不如ADD从对业务和系统最重要的驱动因素开始。
这些驱动因素来自探索过程。业务研讨会可能会揭示用例以及系统必须执行的工作。机会研讨会可能展示系统存在的理由，例如进入新市场、现代化产品或缩短上市时间。技术研讨会展现网络、基础设施、安全和集成方面的约束。质量研讨会则补充系统必须具备的可衡量特性，如可用性、性能、可扩展性、安全性和可测试性。
这是该方法的核心。每一个设计选择都应追溯到一个或多个架构驱动因素。如果存在某个组件，就应该有一个与业务需求、技术约束或质量目标相关联的理由。这种纪律性防止设计陷入习惯、潮流或一厢情愿的幻想。
为什么探索先行
探索之所以重要，是因为架构不是建立在假设之上的，而是建立在已知的驱动因素之上。只有在减少了那些原本会导致返工的未知因素之后，团队才能快速推进。
在AI和云系统中，这一点尤为重要。同一个平台会根据其背后的实际需求不同而以不同的方式失败。需要实时响应的模型服务系统与批处理分析管道需要不同的设计。受监管的数据平台与内部自动化工具需要不同的控制措施。具有严格正常运行时间期望的云应用与可以容忍暂停的应用需要不同的结构。
ADD帮助团队尽早梳理这些差异。它为原本可能显得模糊的过程提供了结构。它不把架构视为一组偏好，而是将其视为对特定驱动因素的响应。
这也是为什么ADD最自然地应用于全新项目（Greenfield）。当系统是全新的时，可以从一开始就围绕驱动因素来塑造架构。当系统已经存在时，其他方法更适合评估现有情况及其不足之处。道理很简单：不同的起点需要不同的方法。
ADD在实践中如何运作
ADD是迭代的。它不会在一次迭代中生成整个架构。它一步步推进，细化系统的某一部分，然后利用所学到的知识来塑造下一部分。
理解该方法的一个实用方式是：首先，选择要设计的系统部分。然后，确定该部分最重要的架构驱动因素。接着，草拟一个能满足这些驱动因素的结构。随后，记录仍未解决的事项，并将剩余的关切带入下一轮迭代。
这种方法很有用，因为它迫使权衡公开化。例如，如果系统必须快速响应，设计可能会倾向于缓存、预计算或更简单的服务边界。如果安全是主要关切，设计可能会倾向于更强的隔离性、更严格的身份控制或更明确的数据处理规则。单一的设计很少能以相同的方式满足所有目标，因此架构必须进行抉择。
考虑一个小例子。一家公司希望拥有一个使用AI从内部文档中建议答案的客户支持助手。业务目标是减少响应延迟并提高一致性。质量驱动因素包括安全性，因为文档可能包含私人信息，以及可用性，因为助手必须在营业时间内可用。
在ADD风格的设计中，团队不会随机挑选工具。他们会首先询问在这些驱动因素下助手应如何行为。这可能导致设计出受控的文档访问权限、检索层、用于审查的日志记录以及围绕模型调用的服务边界。架构的存在是为了满足驱动因素，而不是为了展示技术品味。
这对AI和云系统意味着什么
现代AI系统很少是孤立的。它们依赖于数据源、模型服务、网络路径、身份规则和云资源。这使得架构驱动因素变得更加重要。薄弱的设计可能会隐藏一段时间，然后在用量增长或出现新规则时失败。
ADD为领导者和架构师在构建工作开始前讨论系统提供了更清晰的方式。它使对话具体化。团队不能含糊地说系统应该是“可扩展的”或“安全的”，而必须说明具体的规模、威胁、延迟和数据条件是什么。由于设计与实际需求紧密相连，这会产生更好的决策。
它还改善了探索与实施之间的交接。架构愿景文档可以在一处记录目标结构、路线图、团队形态和工作边界。这为工程师的构建规划提供了更坚实的基础。它也向业务利益相关者提供了更清晰的视角，了解系统被设计用来做什么。
对于EuroOp LLC而言，这是实际的教训。良好的架构始于系统必须满足的事实。ADD的价值在于它使这些事实可见，并将其用作设计输入。这是一种在AI、云和企业工作中经得起考验的模式，其中模糊结构的成本会在后期显现，而且通常是在最糟糕的时候。
EuroOp Insights遵循相同的编辑理念：一个应用的研发模式，一个实用的要点，源自支撑真实系统背后的工作。