This document discusses various premises and realities regarding software architecture patterns. It addresses premises and failures around decomposing monolithic systems into microservices, using domain objects as APIs, and other architectural approaches. Key points made include that implicit coupling through shared databases can persist, services may end up larger than desired, and domain objects can leak implementation details.

1. Michael T. Nygard
@mtnygard

3. This Photo by Unknown Author is licensed under CC BY-NC

4. This Photo by Unknown Author is licensed under CC BY-SA

6. This Photo by Unknown Author is licensed under CC BY-SA

7. UI
Domain
Persistence
Application

8. Users Orders Suppliers Finance

9. Users Orders Suppliers Finance

10. Users Orders Suppliers Finance

11. Monitoring
Logging
Authn/Authz

12. Context
A large system that requires decomposition.
Mix of high-level and low-level concerns
Several operations are at the same level of abstraction
Layers POSA 1
Solution
Therefore, structure your system into an appropriate number of layers and place them
on top of each other.— Buschmann, et. al., Pattern Oriented Software Architecture,
Vol 1.
Each layer should have a narrow, well-specified interface. It should be possible to
substitute a different implementation of the layer without change to higher layers in the
stack.
• Forces
• Late changes should have limited ripple effect
• Interfaces should be stable, may be standardized
• Parts should be interchangeable
• Other systems may reuse lower layers
• Responsibilities should be grouped for
comprehension and maintainability
• Further decomposition is needed for team structure
and design.
Example: TCP stack Failed example: Ruby on Rails
Question: What makes a better or worse implementation of layers?
Layer 1
1.1 1.2 1.3
Layer 2
2.1 2.2
Layer 3
3.1 3.2 3.3
<<uses>>

14. http://www.michaelnygard.com/blog/2015/07/the-fear-cycle/

15. ▪No limits to effect of bad code
▪Common-mode failures in shared code
▪Latent semantic coupling

16. ▪Poor monitoring
▪Poor retry / timeout handling
▪Disruptive deployments

17. ▪ My experience: 2 out of 3 such projects will not
succeed.
▪ The killers:
▪ Impatience
▪ Unrealistic expectations
▪ Hubris

19. ▪ Premise
▪ Refactor to create interfaces between subdomains, then turn those into HTTP interfaces
▪ Failure modes:
1. It takes too long. Executive impatience will defeat the plan.
2. Ongoing feature work introduces new dependencies faster than they are removed.

20. ▪ Tempting to make your key domain objects into services.
▪ Makes deployments more disruptive
▪ Creates common dependency from many features to the entity services.

21. ▪ Premise
▪ Keep developer utilization high by drawing them from a pool for the duration of a project.
▪ When the project is done, throw the developers back into the pool.
▪ Failure modes:
1. Project-orientation favors deadlines over code health & architecture initiatives.
2. Developers doing the hard work of refactoring should be able to enjoy the fruit of their
efforts.
▪ Instead:
1. Use product teams

22. ▪ Premise:
▪ We know the domain, let’s design new services that leave the past behind.
▪ Reality:
▪ We make the same mistakes over and over.
▪ “Second system effect”
▪ Designers’ optimism not supported by any past evidence
▪ Instead:
▪ Design in context.
▪ Accept the scars of the past.

23. ▪ Premise:
▪ Create an intercepting proxy that can divert some kinds of traffic to one new service at a
time.
▪ Reality:
▪ Sometimes works
▪ However, you will not like the service design.
▪ Services must be designed expediently and in the context of the current system’s interaction
▪ That’s OK, they can be replaced easier after the first effort.

24. ▪ Premise:
▪ The current system works.
▪ Devs know what’s needed in their own areas
▪ But are afraid of the far-distant effects of their changes
▪ Response:
▪ Break into “product” teams
▪ Give each one a copy of the code
▪ Let them delete anything they don’t need.
▪ Reality:
▪ Coupling via the DB lasts a long time
▪ Services will be larger than desired

25. ▪ Premise
▪ Microservices are never “done”
▪ Keep the pressure on simplifying design
▪ Reality
▪ Devs are often uncomfortable with ambiguity
▪ Deleting services & code that were just barely deployed feels “wrong”

26. ▪ Premise
▪ Objects with long lifespans that serve multiple uses are hard to change
▪ Therefore, find major boundaries in the business process
▪ Make the “before” and “after” portions into separate services
▪ Reality
▪ Addresses consistency better than entity services
▪ Supports converging business processes
▪ Not as easy to support divergence

27. ▪ Premise
▪ Domain objects make good representations to transfer in APIs
▪ An API can be expressed as REST on domain objects.
▪ Reality
▪ Makes it very difficult to handle multiple versions of APIs
▪ Leaks implementation detail & internals of the service
▪ Instead
▪ Treat request data as data
▪ At most, map into object that represent the interface itself

29. ▪ Premise
▪ Hexagonal architecture expresses the domain independently of integration & persistence
tech
▪ Reality
▪ Improved testability
▪ Smaller domain
▪ Better support for monitoring, metrics, and ALM

33. Michael Nygard (@mtnygard)