- There are different types of coupling in software systems.
- Vlad Khononov proposes a model of coupling that includes four options for assessing the strength of coupling between two components. From strongest to weakest, they are intrusive coupling, model coupling, functional coupling, and contract coupling.
- We should always strive for contract coupling where possible because it is the weakest form and reduces the cost and risk of each change.
- Making subsystems smaller reduces their local complexity but may increase global complexity. It’s important to consider the overall complexity rather than making lots of small pieces.
- Modelling flows and processes are key to uncovering coupling in a design and, therefore, reducing the coupling.
- Eric Evans’s model exploration whirlpool is an effective guide for navigating the design process. It focuses on continuously challenging the model by working through concrete scenarios and getting deeper into the details where necessary.
- Domain Message Flow Modeling is a technique for designing architecture by modeling the interactions between subdomains and their subsystems. It uses a domain-oriented notation that maps closely onto the implementation.
- EventStorming can be used as a starting point for message flow modeling by extracting sequences of events as reference scenarios.
- It’s important to challenge each aspect of a message flow model, like the types of messages, names, and boundaries.
- Choosing between commands and events can have a big effect on the design, especially the decision coupling, which is about deciding which subsystem determines what happens next in the flow.
- When designing architecture, the requirements and scenarios shouldn’t be treated as fixed; you should always treat them as suspect and challenge them based on feedback from the design process.
- A good modelling process will involve exploring many possible models, not just one or two.
- Don’t waste time creating pretty diagrams when modeling; messy is fine.
- Consolidating the information from various scenarios into a single unified design helps assess a subsystem’s overall design. This can be achieved with visual canvases like the bounded context canvas.
- When the overall design for a subsystem is pieced together, bad design choices will stand out, like message names and responsibilities that aren’t consistent with the name or purpose of the subsystem.
- Software design EventStorming (aka design-level EventStorming) can be a stepping stone from conceptual models to code. Each sticky note maps to a granular piece of code, and a new notation—aggregates—is introduced.
- Software design EventStorming can be used to move deeper into the details during the modeling process to get feedback on whether a design will work as code while still allowing visual collaboration.
- The modernization strategy for each subsystem should be decided on a case-by-case basis. Some subsystems will only benefit from lift and shift, while others may benefit from a complete overhaul of the technology stack, infrastructure, functionality, and software design.
- Understanding the potential value and cost of investment needed is key to identifying each subsystem's optimal ROI and migration strategy.
- Migrating from the current state to the target state is probably the hardest part of modernization. There are many migration patterns, like the strangler fig, bubble, and parallel run patterns.
- Assessing the current state of a system can be achieved through various means like using tools, running workshops, and just diving into the code and trying to decouple it in an experimental fashion for discovery purposes.
#Architecture #Modernization #Loosely #coupled #software #architecture
