Author: Jingdong Technology, Ni Xinming

Under the agile development environment, the system delivers incremental value through iterations, and the system architecture is the same. It is impossible for a team to establish a perfect system architecture at the beginning of the project. The system architecture should evolve continuously with the system iterations. Architecture evolution and architecture decay are different perspectives on architecture: architecture decay focuses on the current situation, while architecture evolution emphasizes the future. Architecture decay is inevitable, and the phenomenon of decay will inevitably occur as time goes by. What we need to do is: discover and correct it in advance through some means

1. The problems faced

Focus the attention from the macro perspective of evolution and degradation to more specific issues and challenges. As a team leader or architect, are you facing the following problems:

• The team has already formulatedDevelopment specifications are difficult to implement sustainablyand maintain a high level of health in the application

• The architectural decisions made by the system gradually weaken, break, and even with the passage of time, no one in the team pays attention to the implementation and compliance of the decisions

• Historical architectural decisions have already been 'without a trace', let alone tracing the evolution of the system architecture

• How to quickly judge the current degree of system degradation or health status?

• Whether it is architecture upgrade or system evolution, the system lacks guiding automated constraints to ensure that the evolution direction will not deviate

Based on the above issues, I believe that teams have done some practices, whether it is the strong constraint of the process or the automation of the system, all or some of the problems faced above have been tried to be solved. Typical methods:

• Method one:code review (rigid process)

• Method two:static analysis tools, combined with CICD pipeline

• Method three:Practical experience in architecture constraint unit testing based on ArchUnit

1.1 Code review

Code review is the most typical way to conduct a rigorous review of the code delivery for each iteration, through the participation of multiple stakeholders, it can flexibly and deeply evaluate the compliance with constraints. Of course, the more comprehensive the review, the greater the effort and time cost required by the reviewers.

A large number of development practices have shown thatthe system cannot maintain a high-intensity, comprehensive code review continuously, and the intensity of the review will decrease due to various factors, eventually leading to the degradation of the system. This humanly uncontrollable factor is the main problem of code review.

Another issue is that,The posteriority of code review in the development processGenerally, the actual involvement of code review may be after the development and before the integration, of course, some teams may be even later. The later the process, the more likely there will be a conflict between the refactoring cost and the project cycle if there is a large-scale architectural constraint violation.

1.2 Static analysis tools

There are many static analysis tools for code, such as CheckStyle, FindBug, Sonar, and EOS within the company, etc. These static analysis tools can analyze the specifications of the code, such as comments, naming, code segments that may have potential defects, and cyclomatic complexity.

The greatest advantage of static analysis tools is:

•Platform-based supportRich product matrix: for example, there are PC platforms for customers and IDE plugins for development, etc.

•校验的自动化执行能力：可以通过平台、IDE插件工具或是流水线（如果集成CICD）触发自动化执行并生成分析报告。

静态分析工具的不足主要表现在：

•一般情况下，这些工具仅仅是提供建议的扫描报告，不具强流程控制，在约束打破时不会阻断应用构建。部分工具（并不是所有）与CICD流水线进行了打通，通过质量门禁来干预构建流程，一定程度上能作为系统约束校验的最后卡点。

•静态分析工具的能力侧重点一般在于开发编码规范的约束，比如命名、注释、代码段规约等等，而对于高层的架构约束的校验较弱，比如分层架构约束、”组件“间约束、类位置约束、包与类的包含关系约束等等。

•约束执行的粒度更倾向于统一规范，比如在团队维度、编程语言维度，而实际上忽略了应用级的定制化约束。不同的应用工程具备特定的应用架构风格，基于特定风格下有不同的架构约束。这些差异化规划与团队统一规则存在潜在冲突，并不一定在跨应用下都适用。

1.3 基于ArchUnit

ArchUnit是一个基于Junit运行的架构约束类库，其能够通过单元测试的形式对系统架构约束进行自动化的校验。团队引入ArchUnit的成本并不高，由于是基于单元测试形式引入，并不影响应用程序的主线流程。团队在引入往往有集中形式：

•单个应用引入，每个应用都定义各自的单测

•公共jar包，多应用复用

上述应用模式也同样在统一规范和应用差异化层面存在类似的问题。

1.4 共性问题

以上的三种实践方案存在以下几个共性问题无法解决：

•团队统一规范和应用级别的定制化支持

•架构决策记录的管控与追踪

•多维度的架构指标分析

2 ArchKeeper 平台建设的核心目标

基于对已有问题及解决方案的分析，我们希望平台化的解决方案，ArchKeeper平台建设的核心目标如下：

•架构约束自动化测试能力：支持架构约束的自动化执行

•灵活、简单的规则扩展能力：规则的定制扩展应尽量保持简单、灵活，满足实际的定制化需求

•团队统一规范与应用扩展规则的统一执行

•结果及时反馈，支持与CICD流水线集成：自动化执行前置到开发阶段，并通过CICD流水线作为最后卡点

•ADR管控与追踪：以产品线和应用为载体，对系统的架构决策进行统一管控，并具备ADR的可视化追溯能力

• Static analysis mode of architectural constraints to assess architectural decay: Based on the static analysis capability of the code repository and rule library, to provide high-level application rule analysis reports

• Multi-dimensional architecture governance indicator analysis capability: Provide more multi-dimensional indicators for applications, such as component coupling, etc., to guide architectural evolution

3 Core Concepts of ArchKeeper

Idea One:Architectural constraints are mandatory rules, and the application must comply; otherwise, the application construction should be blocked

The system's architecture decision is an impact on the system's “ImportantAfter the decision review is passed, it should be ensured that the application follows, and the team should evaluate the way of decision execution verification, such as which can be automatically verified and which require manual review. For architectural constraints that support automated verification, the application must comply and cannot violate the constraints. Therefore, if there is a violation of constraints, the application construction should be blocked.

Idea Two:The execution of architectural constraint testing should be as forward as possible, and timely feedback should be provided

The problem brought by post-process is that if there is a violation of architectural constraints, the development team needs to spend a certain amount of time and cost for refactoring. The more backward the process, the higher the refactoring cost. Therefore, the automated execution of architectural constraints should be as forward as possible, in advance to the development stage, and timely feedback of verification results should be provided as much as possible to improve efficiency.

Idea Three:Architectural constraints cannot be completely unified; in addition to the unified norms of the team, application-level customization is allowed, and it must be unified in execution

The scope of architectural constraints is relatively broad, and the team cannot form a completely unified and standardized constraint specification. Some constraints are at the team level, such as some mandatory constraints in coding specifications. While some are at the application level, such as hierarchical constraints under specific applications, etc. Therefore, such customization is inevitable. Although the unified constraints of the team and the customized constraints at the application level cannot be completely unified, both should be executed in a unified automated process.

Idea Four:The system's architecture decision record should be retained and traceable

The system's architecture decision record (ADR) is an important asset of the team. ADR should be kept in a documented form and should be able to provide traceability for the evolution of ADR.

Idea Five:Multi-dimensional architecture indicator analysis is conducive to preventing architectural decay and providing guidance for architectural evolution

The reason why the ArchKeeper platform plans to provide multi-dimensional architecture indicator analysis capabilities is based on such a premise: multi-dimensional architecture indicator analysis of applications is conducive to observing the degradation of the system and provides certain guidance for the evolution of the system's architecture.

4 Conclusion

The article mainly elaborates on the existing problems in the development process and the concept and goal of the ArchKeeper platform construction, without involving specific implementation. Subsequent series of articles will continue to share and communicate on the ArchKeeper capability planning and design implementation (based on DDD).

Related Articles:

Guarding System Architecture through Automated Unit Testing

Lightweight Architecture Decision Record Mechanism