Goal
The path to "Architecture Modernization"
Here is the reading path leading up to this book, derived from its dependencies and ordered from the fundamentals.
The path so far (12 books)
Why read this first: After grasping the basics of readability such as naming and function decomposition, you move on to binding them into principles of why. Clean Code connects individual techniques into a coherent system of craftsmanship and design principles.
Why read this first: After adopting the pragmatic mindset of keeping code healthy, you ground those attitudes in concrete quality standards at the function and class level. Clean Code systematizes what good code is through principles and worked examples.
Why read this first: Once you know what good code looks like, you need techniques to safely move existing code toward that standard. Refactoring offers a systematic way to improve structure without changing behavior, guided by code smells.
Why read this first: Once you can design boundaries inside a system, you face the next decision: whether to split those boundaries into separate processes—services. Monolith to Microservices, guided by the pragmatic 'monolith first' principle, systematizes the motivations, methods, and pitfalls of decomposition.
Why read this first: Once you understand microservice principles, you advance to realistic strategies for migrating from an existing monolith. Most successes peel services off a monolith incrementally, so you also learn when not to distribute from the start.
Why read this first: After mapping the strategic and tactical landscape with an introductory text, you verify the origin and precise definitions of the concepts in the source. Evans' DDD grounds the ubiquitous language and model-driven design, forming the foundation for applied judgment.
Why read this first: As you carve out services, the question becomes whether the unit of decomposition matches the cognitive load of a team. The inverse Conway maneuver reorganizes teams to fit the architecture you want.
Why read this first: Once safe refactoring moves are in hand, you take on the hardest case: legacy code without tests. You first find seams to break dependencies, cover them with tests as a safety net, and only then improve the structure.
Sources
Why read this first: After designing team boundaries for fast flow, you back those boundaries with the language of the business domain. A bounded context defines the outline of both the team and the model at once.
Why read this first: Once you have a grasp of domain models and bounded contexts, you take that thinking into the field of large-scale legacy modernization. This book ties domain decomposition to business goals and team structure, turning it into concrete steps for driving a modernization effort.
Why read this first: Working Effectively with Legacy Code covers the techniques for getting untested code under test by finding seams, and changing it safely. Kill It with Fire works at the level outside that: whether an aging system should be rebuilt at all, whether a migration will add value, and how to tell when a project is finished, argued through case studies. Read with the code-level techniques already in hand, its alternatives to a rewrite are easier to picture concretely.
Why read this first: Kill It with Fire concentrates on judgment: whether to modernize, where maintenance effort pays off, and how to keep an effort's momentum. Architecture Modernization treats modernization as a socio-technical problem and supplies methods for carrying it out, from finding out what the business is trying to achieve through Wardley Mapping and EventStorming to identifying domains and subdomains. The first book settles whether to do it; the second provides tools for doing it.