A distributed system is made of independently running components that communicate over a network and work together as one application. Unlike a monolith, where modules typically call one another inside a single process, its service boundaries turn interactions into network requests. Those boundaries let services be deployed or scaled separately, but make the complete application harder to run and debug. section 1.2
An online shop across service boundaries
A shopper uses a storefront that calls a catalog API. The wider system can include a database, cache, message broker, and background order processing. No single component provides the whole shopping experience; a request may cross several of them. section 1.0 section 1.1
Local development must account for components that start and fail independently:
- Start services and infrastructure with the right configuration, ports, and volumes; a dependency may not be ready when another service starts. section 1.0
- Connect services without relying on hardcoded addresses. Aspire’s AppHost declares resources and their relationships; service discovery resolves hosted applications by their registered names. section 1.0 section 1.10
- Observe the whole request path. Shared logs, metrics, traces, and resource status help expose failures that would otherwise be scattered across processes and terminal windows. section 1.0 section 1.1
Aspire coordinates local development; it does not merge the services into one application. Integration tests can verify behavior across their boundaries, while the application model and dashboard make the running system easier to inspect. section 1.0 section 1.1
Figure 1.2 A distributed application consists of several specialist components separated by network connections.
The diagram makes the network boundaries between specialist components visible. section 1.2
