判断一个概念是否值得纳入架构的两个条件

一旦确认某个核心概念（如[[架构意图的识别案例功能系统与管理系统之别]]里的”管理”）只是架构师自己的设计意图而非现实系统的原始需求，接下来必须回答”这个意图该不该被采纳、规模该多大”——这是一个从”想要什么”到”能要什么”的过渡，作者称之为”控制架构欲望”，是架构师最需要反复自省的素质之一。作者给出两个具体的判断条件：其一（主要条件）是这个概念是否能够被规则化——能不能被抽象成清晰的逻辑规则加上这些规则所依赖的信息（这和结构化程序设计里的”数据+算法”在抽象层面是近似的）；其二（附加收益）是规则化这个概念之后，能不能为系统的其他构件带来额外的便利。只有当主要条件成立、且附加收益足够丰厚时，才应该确认这个意图确有必要被纳入架构——以”组织机构”表达的”人与人的授权”为例，它明显可以被规则化（可以直接写成”如果User1是Manager则可以给User2分配某项权限”这类逻辑判断），同时又能带来一系列后续构件设计上的便利。在权衡这类收益时，作者特别强调”概念完整性”是最重要的一项考量——它决定了整个系统的核心逻辑和描述架构、功能与内部关系的一般方法；如果一个架构设定在概念完整性上没有必要性，它的价值收益通常会偏小、偏局部，顶多是个可备选项。可迁移启发：面对一个”看起来很有道理、但不确定该不该做”的架构设计冲动时，可以用这两个条件依次检验——先问它能不能被清晰地规则化（而不是含糊地停留在”应该有这个概念”的直觉层面），再问规则化之后除了满足这个概念本身，还能不能给系统其他部分带来实质便利、尤其是有没有提升整个系统的概念完整性；两者都成立，这个设计冲动才值得被确认为一个真正的架构意图，而不只是架构师一时的个人偏好。