Architectural Refactoring
•Download as PPTX, PDF•
0 likes•1,155 views
The document discusses architectural refactoring, which is intentionally changing a system's structure without altering its features. Reasons for refactoring include when technology fails to meet user needs or the team fails to deliver for the organization. Common patterns of refactoring include building a monolith initially for speed but later leveraging distributed caching, clustering servers, eliminating session state, and separating data from static assets. The goal is to trade total complexity for local simplicity over time through refactoring.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Architectural Refactoring
Similar to Architectural Refactoring (20)
More from David Adsit
Recently uploaded
Recently uploaded (20)
Architectural Refactoring
- 2. Dave Adsit Chief Application Architect @davidadsit codeobsession.blogspot.com
- 3. A mostly true story of architectural evolution
- 4. What is Software Architecture? Architecture is the stuff that’s hard to change. Martin Fowler
- 5. What is Refactoring? Refactoring is a changing the structure of code without changing its behavior.
- 6. What is Architectural Refactoring? Intentionally changing the structure of a system without altering its features.
- 7. Why would anyone do that? The technology fails to meet the needs of users The team fails to deliver on the needs of the organization
- 8. Patterns of change A generally reusable solution to a commonly occurring problem within a given context
- 9. Build a monolith Fast and easy Can be done with a small team Allows for quick changes No need for QA handoff No need for Ops handoff
- 10. Leverage a distributed web cache (CDN) Offload traffic from a web server Improve response time for users far away
- 11. Cluster the servers Distribute load Improve reliability Move from physical to virtual machines
- 12. Eliminate session state No more sessions pinned to servers Replace session data with user data
- 13. Replace feature branches with feature toggles Integrate continuously Decouple deploy from release Ability to disable features that don’t work out
- 14. Separate data and static assets Reduce server-side rendering load Leverage client processing power Improve quantity and granularity of caching <html>...</html> { … }
- 15. Shard the database Partitioning data to distribute load
- 16. Introduce a polyglot datastore Document database for fast reads SQL database for ad hoc reporting and research Miscellaneous special purpose databases
- 17. Replace database queue(s) with real queue(s) Don’t implement a queue in a database Guaranteed at least once delivery
- 19. Split the team Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. Melvin Conway
- 21. West Redundant datacenters Increase reliability Simplify disaster recovery Reduce response time East
- 22. Extract bounded context Microservices Microsites Shared datastore Anti-corruption layer
- 23. Strangle the monolith Repeat extract context until no more than a single context remains behind
- 24. Distributed system of record One bounded context is the system of record Others have local caches of relevant information used to make local decisions
- 25. Implement async communication pattern Publish/Subscribe Leverage the queue for reliable delivery
- 26. Implement blocking communication pattern Request/Response RESTful APIs Circuit breaker
- 27. Orchestration and choreography Conductors direct orchestras Dancers in a ballet act independently
- 28. Trade total complexity for local simplicity
- 29. How long will it take?
- 30. Questions? Dave Adsit Chief Application Architect @davidadsit codeobsession.blogspot.com