架构自查几个主要项

目录

• 背景和价值
  • 应用架构
  • 数据架构
  • 技术架构
  • 非功能性需求
• 参考资料

背景和价值

应用架构

检查项	价值	示例	措施
是否存在实体和所在的界限上下文不符	提升沟通效率。强化问题解决: 清晰的问题边界有利于找出更切合实际的解决方案,并更好地进行方案实施和评估。	间接客户的实体在政策服务。而不是在客户模块统一管理。	强制
是否存在双向依赖	显式的紧耦合，可能导致死锁、级联故障或逻辑混乱	反例：容器(微服务)之间依赖关系形成了环。注意：消息机制不作为依赖关系的一部分	推荐
是否存在依赖	依赖关系更隐蔽，通常由服务拆分不合理或业务逻辑复杂导致，可能引发系统级联故障。	反例：容器(微服务)之间依赖关系形成了环。注意：消息机制不作为依赖关系的一部分	推荐

数据架构

检查项	价值	示例	措施
是否有跟应用架构中领域模型关联关系不一致的关联关系	概念模型中的概念间关系的价值在于确保关联关系的合理性、一致性，以及提供清晰的定义，以支持数据的准确关联和信息的流动。	---	---

技术架构

检查项	价值	示例	措施
是否符合集成规范		某接口跨系统调用没有走集成网关
是否对集成接口的数据量进行评估和设计（大数据量需选用不同的方案）			是否对于外部集成超时时间大于10s的接口进行审视
是否接口幂等性进行设计
是否对系统最终一致性进行设计
发生数据不一致的情况时是否可观测、可处理
DDD save当做update容易出现ABA问题。
如果业务频繁因为ABA问题出现数据不一致，需要做改造，否则不用改造。
改造方案1（推荐）：非save写法，就是mybatis 写sql直接 更新某个字段
方案2：使用乐观锁。 批量更新的时候，容易都失败。
对多个功能使用的能力是否进行通用设计，例如技术组件
当重大错误发生时，是否进行了主动告警和通知相关人员的设计
明细批量处理，不能做全删除，全插入，会引发数据库大量读写；建议按照id处理，是否需要更新、插入或者删除，减少数据库压力
字段筛选，要优先使用数据库过滤，尽可能使用索引，并确保索引的有效性,避免将数据加载到内存，在内存里面做筛选。
大数据量处理时，分页查询，处理之后，释放内存对象，再进行下一页请求处理，避免OOM。
定时任务是否满足 1 可重试执行，可按每天或者某条实体 2 可观测 3 幂等性 4 一致性。如果定时任务存在强依赖，前置任务失败不允许后置任务执行

非功能性需求

在非核心业务和功能出现故障后，核心业务是否能够正常提供能力.
如MDM发布，调用Base获取子库的接口不宜失败。（
在外部系统主数据数据量不是很大的情况下，宜将以外部系统的主数据同步到系统，避免外部系统的不稳定）订单调用供应链，失败，要提供重试的功能

参考资料