system-topology

To decide on system topology, you compare explicit constraints against a catalogue of seven topologies. The default recommendation is a modular monolith unless measured constraints justify a different architecture.

Justifying system topology requires providing measured justifications for your choice against an enumerated alternative set. This ensures design decisions for cross-boundary services are explicitly documented rather than assumed.

You need to evaluate system topology during design planning for new systems involving cross-boundary processes, services, or deploys. It forces an explicit choice between architecture patterns using documented constraints.

Start a design plan by running the skill to follow prompts that guide your system topology decision. It suggests defaulting to a modular monolith unless you provide measured constraints that justify another topology.

Choosing microservices without measured constraints bypasses explicit decision making against alternatives like a modular monolith. Without documented justification, you risk selecting a topology that does not fit your system design needs.

Yes, you can use this approach for any design planning involving cross-boundary processes, services, or deploys. It requires documented constraints and measured justification to validate the chosen system topology.