"The Intersection of architecture and implementation", Mark Richards
0 likes485 views
The document discusses the importance of scalable and high-performance architecture, particularly in microservices, and emphasizes the significance of aligning architecture with both domain and implementation shapes. It highlights the need for effective communication between software architects and development teams, advocating for architecture decision records to facilitate understanding and consensus on critical decisions. Additionally, the text addresses maintaining structural integrity and the necessity for continuous architectural evolution in response to changing requirements.
"The Intersection of architecture and implementation", Mark Richards
- 2. “We need an architecture that can scale to 500,000 users with an average response of 600ms under full load” “No problem. I’m on it. business sponsor software architect
- 3. “Here’s the architecture for the new system…” software architect development team
- 4. “What protocol should we use between services?” “That’s an implementation detail…” software architect development team
- 5. “What persistence framework should we use?” “That’s also an implementation detail…” software architect development team
- 6. “What third-party libraries and services should we use?” “Again, an implementation detail. Architecture is my job— implementation is yours.” software architect development team
- 9. isomorphism
- 10. isomorphism isos (meaning “equal”) and morphe (meaning “form”, or “shape”) how close does the shape of one thing match the shape of the other thing?
- 11. how close does the shape of the architecture match the shape of the problem domain? architecture to domain isomorphism
- 12. microservices architecture single purpose functions deployed as separate units with each unit owning its own data
- 13. layered architecture single deployment with functionality grouped by technical categories
- 14. how close does the shape of the architecture match the shape of the implementation? architecture to implementation isomorphism
- 15. how close does the shape of the architecture match the shape of the implementation? architecture to implementation isomorphism
- 16. Case Studies
- 17. “We’re expecting anywhere from several thousand to a million concurrent customers on the new system.”
- 20. item_id current_inv max_inv min_inv Inventory get current inventory Too slow, and the services are too tightly coupled together
- 21. item_id current_inv max_inv min_inv Inventory update-able in-memory cache containing inventory amounts read-only replicated cache containing inventory amounts
- 22. item_id current_inv max_inv min_inv Inventory Much faster, and the services are decoupled and no longer dependent on each other
- 23. 500 mb 500 mb 1.0 GB
- 24. 1000 mb 2500 mb 3.5 GB
- 25. 1500 mb 2500 mb 4.0 GB
- 26. 1500 mb 2500 mb 4.0 GB https://myapp.com/placeOrder?id=27a54826s Service Unavailable HTTP ERROR 503. The service is unavailable
- 29. “We have a very tight budget and timeframe for this new venture, and we’re expecting a significant amount of change to the underlying data structures as we learn more about this new line of business. We need to move fast when those changes happen.”
- 31. persistence layer component component component presentation layer business layer component component component component component component services layer component component component Layers of isolation Separation of concerns Good change control software architect
- 32. persistence layer component component component presentation layer business layer component component component component component component services layer component component component Better performance calling the database directly It’s easier having the code and SQL together
- 33. persistence layer component component component presentation layer business layer component component component component component component services layer component component component
- 34. “Wait—here’s the best part—then they said ‘Sure, we’ll have those database changes out to you right away.’ Ha ha ha ha ha ha ha…” persistence layer component component component presentation layer business layer component component component component component component services layer component component component
- 37. How does implementation get out of alignment with architecture, and how can we prevent it from happening?
- 38. communication
- 39. “The most effective way to deal with constant database change is to leverage closed layers in the architecture. I’ve got to let the development team know…” software architect development team
- 40. Architecture Decision Records to the Rescue!
- 41. short text file; 1-2 pages long, one file per decision (markdown, textile, asciidoc, plaintext, etc.) architecture decision records short noun phrase describing the decision proposed, accepted, superseded description of the problem and alternative solutions available (documentation) justification (the “why”) tradeoffs and impact of decision
- 42. if developers don't know why you made a decision, they are less likely to agree with it “Do this.” software architect development team “No. We don’t agree.”
- 43. Second Law of Software Architecture “Why is more important than how” ?
- 44. justification (the “why”) tradeoffs and impact of decision architecture decision records
- 47. collaboration
- 49. software architecture software development availability scalability performance
- 50. software architecture software development leadership mentoring availability scalability performance
- 51. if developers are not involved in the decision, they will be less likely to follow it “Do this because it performs better.” software architect development team “Okay.” “We found a better way to do this.” later…
- 52. “We’re going to use request/reply messaging between our services because it’s faster and more scalable.” software architect “Actually, we decided to use REST because it’s just as fast and it scales better than messaging. Look it up on Google or ChatGPT.” development team the problem…
- 53. “But…but…this is my decision…and messaging is faster and more scalable in our environment…” software architect “Whatever. We’re moving forward with REST.” development team the problem…
- 55. “I ran some benchmarks between REST and messaging in our production environment. Take a look at this…” software architect development team demonstration defeats discussion
- 56. response times user load REST Messaging This is our expected load Our production environment This is our response time SLA demonstration defeats discussion
- 57. “Based on this, I’m thinking we should probably use messaging to communicate between our microservices. What do you think?” software architect “We were thinking of using REST, but you’re right—based on this data, messaging is a better choice.” development team demonstration defeats discussion
- 58. proposed, accepted, superseded architecture decision records
- 59. Status: RFC by 22 June … indicates request for comments status prior to the decision being made with an end date
- 60. Accepted Proposed Status: RFC by 22 June
- 63. Microservices
- 64. Microservices
- 66. “I hope the development team is complying with the architecture decisions I communicated through the ADR” software architect development team
- 67. “With all these coding changes, I hope the architecture is still meeting its scalability requirements.” software architect development team
- 68. “An architectural fitness function provides an objective integrity assessment of some architectural characteristic(s).” architecture fitness functions
- 69. start if (c1) f1() f2() if (c2) f3() f4() end 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 nodes edges
- 70. response times ! threshold or trend reached track architecture fitness functions
- 71. average duration time concurrent users testing elasticity and scalability operational characteristics response time trend analysis instances starting instances started
- 72. only the business and service layers can access the persistence layer to control change throughout the architecture structural integrity
- 76. H https://www.hello2morrow.com/products/ sonargraph/architect9 structural integrity
- 77. @Test public void presentation_layer_cannot_access_persistence_layer() { noClasses().that().resideInAPackage("..presentation..") .should().accessClassesThat().resideInAPackage("..persistence..") .because("we have a closed-layered architecture to control changes " + "made in the database and persistence layer. Persistence " + "layer can only communicate with the business layer.") .check(myClasses); } structural integrity
- 78. public Presentation_Layer_Cannot_Access_Persistence_Layer() { var result = Types.InCurrentDomain() .That() .ResideInNamespace("Myapp.Presentation") .ShouldNot() .HaveDependencyOn("Myapp.Persistence") .GetResult().IsSuccessful; } structural integrity
- 80. “Developers should never take components designed by architects as the last word. Rather, the initial design should be viewed as a first draft, where implementation will reveal more details and refinements.” embrace continuous architecture change