This article mainly talks about evolutionary architecture
Its definition reads as follows:
An evolutionary architecture supports incremental, guided change as a first principle across multiple dimensions.
Translated roughly, evolutionary architecture is an architecture that supports incremental and guided changes as the first principle across multiple dimensions.
There are several elements involved here:
- Incremental change
- Guided change with fitness functions
- Appropriate coupling
Incremental changes mainly include two parts, one is how software is incrementally built and the other is how they are deployed.
Incremental change describes two aspects of software architecture: how teams build software incrementally and how they deploy it.
Incremental construction, such as forward compatibility and multi-version support; If deployed, such as blue-green deployment, canary deployment, feature toggles, etc.
It requires these changes to be reversible, that is, they can be rolled back. Of course, some structures are used for abandonment/sacrifice. such asSacrificable architectureAs mentioned in:
Guided change with fitness functions
The English definition is as follows:
a particular type of objective function that is used to summarize…how close a given design solution is to achieving the set aims.
It is an objective function to guide us how to tradeoff to satisfy the selected capability.
The premise of defining fitness function is to determine which capabilities need to be maintained and which capabilities can be weakened or removed in the current evolutionary architecture.
As shown in the figure, among the 10 capability selected here, High Thoughput and Data Security are the targets with the highest priority.
Complete capability (
system quality attributes) as follows:
accessibility accountability accuracy adaptability administrability affordability agility [Toll] (see Common Subsets below) auditability autonomy [Erl] availability compatibility composability [Erl] configurability correctness credibility customizability debugability degradability determinability demonstrability dependability deployability discoverability [Erl] distributability durability effectiveness efficiency evolvability extensibility failure transparency fault-tolerance fidelity flexibility inspectability installability integrity interchangeability interoperability [Erl] learnability maintainability manageability mobility modifiability modularity operability orthogonality portability precision predictability process capabilities producibility provability recoverability relevance reliability repeatability reproducibility resilience responsiveness reusability [Erl] robustness safety scalability seamlessness self-sustainability serviceability (a.k.a. supportability) securability simplicity stability standards compliance survivability sustainability tailorability testability timeliness traceability transparency ubiquity understandability upgradability vulnerability usability
There is no perfect architecture that can cope with all changes. The technical architecture is often designed according to the technical conditions at that time. When the restrictive factors change, the technical architecture also needs to change accordingly. For example, there used to be only relational databases, and many designs revolved around normal forms. Now with nosql, it is not necessary to adopt relational databases. polyglot architecture can be introduced. You can freely choose which data is suitable for nosql and which is suitable for relational databases.
Therefore, Appropriate coupling is the core of evolutionary architecture, which is used to tradeoff and which can provide the best benefits at the lowest cost while allowing moderate coupling. For example, micro-service architecture is very opposed to coupling caused by code-level reuse dependency such as service hub, and prefers to use rest and copy code to decouple. Of course, if these service hubs are mature enough to not change/iterate quickly or have incompatible things, then it is also possible to appropriately adopt service hub coupling. However, if the dependent service hubs are undergoing high-speed iteration and change, then this coupling is relatively serious and needs to be chosen according to different scenarios.
Evolutional architecture is different from predictable architecture, which is similar to static architecture and relies on predicting future changes. None of the architectures can cope with all the unknown changes. Evolutional architecture embraces the unknown changes and constantly chooses and chooses among the different changes for evolution.