Draft preview. This note is planned and not yet published; the full version will replace this draft.
Engineering Notes
PlannedSoftware Architecture·Reading time on publish

C4 Modeling as a Starting Point for Software Architecture

Why context and container views come before technology choices — and how a small set of diagrams keeps architecture conversations grounded.

Hamed RezaeiSoftware Engineer & Architecture Consultant

Why start with context

A context diagram names the people and systems around yours before any technology is chosen. It turns the system boundary into a decision rather than an accident, and it gives business and engineering stakeholders one picture they can both correct.

C4 · Context · example
Customerperson
Ordering systemsystem in scope
Payment providerexternal
Illustrative example, not a client system.

Containers before components

The container view shows the deployable pieces and how they talk. It is the level where most early trade-offs live: one service or several, a queue or a direct call, which data store owns what.

Program.csC#
// a background worker is a container decision, not an implementation detail
builder.Services.AddHangfire(cfg => cfg.UseSqlServerStorage(connectionString));
builder.Services.AddHangfireServer();

Diagrams and decisions

Every arrow worth drawing usually hides a decision worth recording. Pair the container view with short Architecture Decision Records: context, options, the choice, and what would make you revisit it.

Clarity is a deliverable. Trade-offs are part of the work.

A worked decision

Take the background worker above. On the container diagram it is either a box inside the web application or a box of its own, and the choice is worth writing down:

Context

Reports and synchronization jobs run for minutes and must survive web deployments. The team is small and runs a single SQL Server.

Options

(A) Run Hangfire inside the web application. (B) Run a separate worker service that shares the same Hangfire storage.

Decision

Option B. Long jobs no longer compete with web requests for resources, and the web application can be redeployed without interrupting them.

Trade-off

One more deployable to build, monitor and version, and job code must stay compatible with both hosts during a release.

Revisit if

Job volume stays low and the second deployable costs more attention than it saves.

The diagram makes the question visible; the record keeps the reasoning after the people in the room have moved on.

Illustrative example, not a client system.

When to stop drawing

Component diagrams are useful for the parts of the system that are changing or misunderstood. Elsewhere, the code and the tests are the more accurate documentation.

Related notes

PlannedSystem Modernization

Greenfield vs. Brownfield: Different Problems, Different Engineering Decisions

PlannedAI-Native Engineering

Building Reliable AI-Assisted Software Delivery Workflows

Need help applying this to your system?

Discuss a Project