Domain vs Infrastructure

For a software architecture, consider which aspects express the

• Domain Model
  • the objects and processes that directly describe and enable the use cases of the system.
• Infrastructure
  • the components which provide support to the domain model’s implementation and function

Example

Imagine you have a shared address book application. Contacts, groups and actions like sending bulk emails would be part of the Domain. The database, containers and message queues would be part of the Infrastructure.

So?

Besides decoupling components (SOC) to support a flexible code base, I use the domain vs infrastructure framing to prioritize.

• when designing and reviewing architecture plans, start with the domain model and defer considering the infrastructure
  • it can be tempting to dive into scalability, databases, etc. but these are a secondary concern and wholly depend on the domain model
  • if you don’t understand nor have a compelling use case, embodied in a reasonable domain model, infrastructure won’t matter

This is similar to Essential vs Incidental, but the perspective is architecture.

For similar ideas, see logical vs physical architectures