LIST

Architecture pattern: global dns + regional load balancers

Global server load balancing (GSLB) with DNS regional Load Balancers (src: Book_ release it! - Michael Nygard)

August 16, 2022

Pattern: canary deployments

small set of instances that get the new build first. For a period of time, instances running the new build coexist with instances running the old build If the canary instances behave oddly, or their metrics go south, then the build is not rolled out to the remaining population todo: ref handling versions - peaceful side-by side running of different versions (src: Book_ release it! - Michael Nygard)

August 16, 2022

Pattern: immutable infrastructure (aka phoenix server)

Don’t change runtime instances Destroy and recreate Always start from a stable, known base image (src: Book_ release it! - Michael Nygard) (src: Evolutionary Architecture - 9. Guidelines for Evolutionary Architecture)

August 16, 2022

Pattern: put all dependencies in a private repository

Pattern: put all dependencies in a private repository Code (eg. Maven) Pipeline (eg. Jenkins plugins) (src: Book_ release it! - Michael Nygard)

August 16, 2022

Pattern: split deployment view and runtime view

Pattern: split deployment view and runtime view Deployment view Transform sources into binaries Transform binaries into deplotments Runtime view Processes running on machines (src: Book_ release it! - Michael Nygard)

August 16, 2022

Pattern: use SLA to determine when to start load shedding

Stability Pattern_ Shed load turn away load we can't complete in time Where? Load balancers How? Health check + SLA a good health check on the first tier of services can inform the load balancer when response times are too high (in other words, higher than the SLA) Model_ health check Own response time services can measure their own response time to help with this. They can also check their own operational state to see if requests will be answered in a timely fashion....

August 16, 2022

Pattern: Adapter Layer for 3rd party integration

Following this approach consistently produces a set of interfaces that define the relationship between our application and the rest of the world in our application’s terms and discourages low-level technical concepts from leaking into the application domain model. benefits: define the relationship of our application the rest of the world in our application’s terms prevent low-level technical concepts in domain model (src: Book_ Growing Object Oriented Software, Guided By Tests - Steve Freeman & Nat Pryce)

February 2, 2021

Pattern: Integration test should mock application objects

(src: Book_ Growing Object Oriented Software, Guided By Tests - Steve Freeman & Nat Pryce)

February 2, 2021

Pattern: Split what and how when naming

Interface name vs Implementing class name Interface name what it does point of view = “user” object Implementing class name how it does it point of view = implementation (src: Book_ Growing Object Oriented Software, Guided By Tests - Steve Freeman & Nat Pryce) Method name should describe what it does, not how Method name should be what it does point of view = “user” object instead of how it does it point of view = implementation src: ?...

February 2, 2021

Pattern: Include the deployment step in the testing process

Pattern: Include the deployment step in the testing process We want our test to - start from scratch, - build a deployable system, - deploy it into a production-like environment, and then - run the tests through the deployed system benefits deployment is error prone => now covered by tests development team bumps into the rest of the organization If it’s going to take six weeks and four signatures to set up a database, we want to know now, not two weeks before delivery....

January 31, 2021