Finding modules in a big ball of mud

The post says a big ball of mud is a normal starting point when software is already working, and that trying to lock in the wrong architecture too early can make things worse. It recommends looking for natural module boundaries in dependencies and in the business domain.

Reading notes

#

• A tangled codebase is presented as something to expect once the software works, not as proof of failure.
• A wrong architecture can create more pain than no architecture, as shown by the microservice example that became hard to change and was eventually thrown away.
• Code can be viewed as a dependency graph at different levels, from functions to systems, with boxes for units of code and lines for their connections.
• A dependency matrix can make structure and messiness visible by showing where connections cluster or spread evenly.
• Dense internal connections with few external ones point to natural modules.
• Some module boundaries cut across existing boxes, especially when shared implementation hides separate concerns.
• Whiteboards and paper help when deciding whether similar code should stay together or split apart.
• The post ties good architecture to the business domain and to domain driven design.
• Event storming is described as a way to uncover events, commands, actors, and business processes with stakeholders.
• The goal is a core business logic module with separate interfaces for different actors so the system feels obvious and simple.