自定义洞察规则：你的架构，你的标准

架构洞察自发布以来一直是Archyl最受欢迎的功能之一。将分析器指向你的架构，它会识别潜在问题：单点故障、循环依赖、孤立元素、缺失文档。团队告诉我们这就像有一位高级架构师在持续审查他们的系统设计。

但我们不断听到相同的反馈："那个警告不适用于我们。"

也许你的微服务在逐步迁移期间有意共享数据库。也许某个组件有很多入向依赖是因为它是一个共享工具库——不是耦合问题，而是良好的代码复用。或者你的团队已经决定一个服务有八个连接是可以接受的，尽管我们的默认阈值会标记它。

通用规则无法考虑你的上下文。所以我们把控制权交给你。

七条规则，你的阈值

Archyl现在允许你自定义分析架构的洞察规则。我们识别了七种对架构健康重要的模式，你现在可以调整每一条以匹配你的团队标准。

单点故障检测器找到太多其他组件依赖的元素。默认情况下，我们标记三个或更多入向依赖的任何元素，但如果你的架构有意集中某些关注点，可以将阈值提高到五、十或任何合理的数值。

高耦合分析查看两个方向：依赖太多东西的元素（出向）和太多东西依赖的元素（入向）。默认值——六个出向、四个入向——适用于大多数代码库，但构建共享库的平台团队可能需要比构建专注功能的产品团队更高的阈值。

过度连接的元素捕获不同的问题：总连接数太多以至于难以推理的组件。

循环依赖几乎总是有问题的。这个规则是二进制的：开或关。

孤立元素找到没有任何连接的架构组件。

安全模式检测有问题的架构选择，如外部系统直接访问数据库。

缺失文档帮助维护覆盖率。

组织范围的一致性

这些设置适用于你的整个组织，而不是按项目。我们有意做出了这个选择。

架构标准应该是一致的。如果你的平台团队决定四个入向依赖是高耦合的阈值，这个标准应该在所有地方适用。新项目自动继承组织的规则。

开始使用

自定义洞察规则在所有计划中可用。导航到洞察，点击规则标签，开始调整。

我们建议从默认值开始，根据你看到的内容进行调整。如果某个特定规则产生了你一直忽略的警告，这是一个信号，要么修复底层架构，要么调整阈值。两者都是有效的选择——目标是让洞察可操作，而不是追逐任意指标。

你的架构有自己的特征、自己有意的权衡、自己对"足够好"的定义。现在你的治理可以反映这一点。

想了解AI驱动的洞察是如何工作的？阅读AI驱动的架构发现，了解Archyl如何分析你的代码库并生成架构建议。