Interesting concept for refactoring and ensuring it works as it used to.
Chapter 4: Architectural Coupling
Architectural Quanta (p48)
"An architectural quantum is an independently deployable component with high functional cohesion, which includes all the structural elements required for the system to function properly."
I personally don't love the term (Robert Raposa). IDA is the closest that edX might have to a term for this, but the architectural soundness isn't part of the definition of an IDA.
DDD "Bounded Context" is mentioned. I prefer this term (Robert Raposa).
Microservices (p68) (their exemplar)
Appropriate coupling (p72)
Typically two kinds of coupling: integration and service template.
Humorous Nit: They attempt to clarify the difference between these two terms, but they provide a definition for "refactoring" that contains the term "restructuring", but the definition doesn't use it the way they are trying to define "restructuring."
Fluid v Guarded Dependencies (p118-119)
Sounds interesting. Mentions tooling isn't available. Could we automate more package updates than we do now?
Version Services Internally (p119)
May make sense, but missing detail regarding how the logic is to "determine the context of the caller" to choose the version. Mentions "request type".
Chapter 7: Evolutionary Architecture Pitfalls and Antipatterns
Antipattern: Code Reuse Abuse (p128)
Reusing domain model code is risky.
Goldilocks Governance (p134)
Small, Medium, and Large recommended technology stacks.
Makes sense that you'd want some balance other than a free for all. At Pearson, we had a map of technology choices which were experimental through supported.
Chapter 8: Putting Evolutionary Architecture into Practice
Product over Project (p144)
Mentions importance of organizing by product and not by project.
We do not do this and the pain is clear. It is not clear what pain or benefits we would see if we tried this.