Build cross-functional team to match an intended micro-service to have the team organized against the intended architecture.
Chapter 2: Fitness Functions
May be useful to use a common term and have a common lens, but not a new concept.
Fitness Function Categories (p18)
Examples: Atomic v. Holistic, Triggered v. Continual, Static v. Dynamic, etc.
Would have liked to see more examples for common -ility use-cases.
Sample gaps at edX (which have come up before):
Dependency checking (see JDepend example, p30)
Potential Discussion (Robert Raposa): automation as a requirement for providing high value (versus docs or OEPs without teeth).
"Without guidance, evolutionary architecture becomes simply a reactionary architecture."
"Monitoring-driven development (MDD) is another testing technique gaining popularity. Rather than relying solely on tests to verify system results, MDD uses monitors in production to assess both technical and business health." New Relic has a lot of functionality to support this.
Chapter 3: Engineering Incremental Change
Example of introducing a new version of a service and automatically garbage collecting the old version when it is out of use.
Is this possible? Is this worth the effort of automation? What about legacy code?
Mentions "Version Services Internally", discussed on p119, but lacking details.
JDepend is mentioned for automating checks of coupling and dependency directionality; we can use snakefood and related tools to do the same in Python. We already have some scripts in edx-platform that start to do this, we should automate them and expand on this. (Jeremy Bowman (Deactivated))
"We prefer building unit tests to catch architecture violations over using strict development guidelines"
"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.
"By defining the appropriate technical architecture coupling points in service templates, an infrastructure team can manage that coupling while freeing individual service teams from worrying about it."
Potential Discussion (Robert Raposa): Relates to new service maturity model. In what cases is this good enough?
Chapter 5: Evolutionary Data
"Architects sometimes err in trying to build an architecture with a smaller level of granularity than is natural for the business."
"don’t take the name microservices too literally—each service doesn’t have to be small, but rather capture a useful bounded context."
Chapter 6: Building Evolvable Architectures
Refactoring v Restructuring (p99)
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".
"Cycle time is the Continuous Delivery measure of engineering efficiency. Part of the responsibility of developers on projects that support evolutionary architecture is to maintain good cycle time."
"Architects must vigilantly watch for situations where nonfunctional requirements break and retrofit the architecture with fitness functions to prevent future problems."
"While Continuous Delivery practices don’t guarantee evolutionary architecture, it is almost impossible without them."
"We encourage architects to start thinking of all kinds of architectural verification mechanisms as fitness functions, including things they have previously considered ad hocly."
"Most developers would rather write a framework than use a framework to create something useful: Meta-work is more interesting than work."
"All problems in computer science can be solved by another level of indirection, except of course for the problem of too many indirections. --Dave Wheeler and Kevlin Henney"
"Theabstraction distraction anti-pattern describes the scenario where a project “wires” itself too much to an external library, either commercial or open source." - resolve via anticorruption layers.
"Because frameworks are a fundamental part of applications, teams must be aggressive about pursuing updates."
Guidelines for building evolutionary architectures
Make decisions reversible
Evolvable over predictable
Service template (shared libraries, etc)
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.
Pitfall: Planning Horizons
"Beware of long planning cycles that force architects into irreversible decisions and find ways to keep options open. Breaking large programs of work into smaller, early deliverables tests the feasibility of both the architectural choices and the development infrastructure."
Pitfall: Lack of speed to release
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.
"The first time you do something, you just do it. The second time you do something similar, you wince at the duplication, but you do the duplicate thing anyway. The third time you do something similar, you refactor."