Versions Compared

Old Version 1

changes.mady.by.user Robert Raposa

Saved on

compared with

New Version 2

changes.mady.by.user Robert Raposa

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Info

These notes are not comprehensive in any way.  They capture a collection of assorted thoughts that came up while reading.


Notes on Building Evolutionary Architectures, Support Constant Change by Neal Ford, Rebecca Parsons & Patrick Kua

Table of Contents

Chapter 1: Software Architecture

  • Inverse Conway Maneuver (p12)
    • Build cross-functional team to match an intended micro-service to have the team organized against the intended architecture.

Chapter 2: Fitness Functions

  • 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):
        • Code complexity
        • Dependency checking (see JDepend example, p30)
        • Performance

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.
  • Feature Toggles
    • Reminder of using feature toggles to test in Production for individuals. (p35)
  • Github Scientist (p37)
    • 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)

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".

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.