The box labeled "Booking API" means something different depending on the drawing. It can be the system a customer uses, a process handling a request, a home for code, or a program running on a server. Put all four meanings in one architecture diagram and even a correctly drawn arrow becomes hard to interpret.

Here are four views of the same fictional appointment service. Each answers a different question about one booking. The sketches are conceptual, and their names stay consistent so you can trace an element from one view to another. The Software Engineering Institute's Views and Beyond guidance describes documenting architecture through relevant views and the information that connects them. This article applies that idea to a small example; the four sketches are not a prescribed set for every system.

The service and its booking rule

Harbor Cuts lets a customer book one available appointment at a shop. Staff maintain opening hours. After a successful booking, the service asks an external Email provider to send a confirmation. The service has a Booking API and a Booking DB. A slot has one shop, start time, and chair. The example assumes the database enforces one active booking per slot, while application code checks opening hours before it tries to save. It leaves authentication, cancellations, time zones, and payment outside the drawing.

Those assumptions matter. A plain "check availability, then insert" sequence can race when two customers choose the same slot. The database constraint is the final guard in this example; the API must turn a rejected insert into a useful "slot taken" response. A diagram can show where that rule belongs, but cannot establish that the code implements it correctly.

Context view: who depends on the service?

Conceptual context view
Customer -- requests an appointment --> Harbor Cuts booking service
Staff -- maintains opening hours --> Harbor Cuts booking service
Harbor Cuts booking service -- requests confirmation delivery --> Email provider

The center box is the whole booking service, including its API and database. The arrows cross its boundary: the customer requests an appointment, staff supply hours, and the service requests an email from a provider it does not control. This view helps a new teammate ask who needs the system and which external party participates in a booking.

It deliberately hides the Booking API, Booking DB, and order of operations. The arrow to the Email provider does not say whether delivery happens before the customer receives a response. If that timing matters, move to a runtime view rather than adding internal boxes to this one.

Runtime view: what happens during one request?

Conceptual runtime path for a successful booking
Customer browser -- POST appointment request --> Booking API
Booking API -- read opening hours; insert booking --> Booking DB
Booking DB -- booking ID, or slot conflict --> Booking API
Booking API -- send confirmation request --> Email provider
Booking API -- booking ID --> Customer browser

Now the boxes represent participants in one execution, and arrow order matters. The Booking API checks the hours and attempts the insert. In the successful path shown, it calls the Email provider after the database commits, then returns the booking ID. If the insert conflicts, it skips the email call and tells the customer the slot is taken. If email fails after the commit, the booking still exists. The team must decide what the response says and how to recover the missing confirmation.

This view answers a request-path question that the context view cannot. It also hides where the opening-hours rule lives in code and which machines run these participants. The Email provider is an external runtime participant; it is not a module inside the Booking API.

Module view: where does the rule live in code?

Conceptual modules inside the Booking API code
Booking handler -- invokes --> Reservation service
Reservation service -- asks --> Opening-hours policy
Reservation service -- saves through --> Appointment repository
Booking handler -- invokes after success --> Confirmation sender

These arrows mean code calls or dependencies, not network traffic. The Booking handler accepts the request and maps a slot conflict to a response. The Reservation service coordinates the booking. It asks the Opening-hours policy whether the requested slot is within staff hours and writes through the Appointment repository. The repository uses the Booking DB, whose unique constraint rejects a competing booking. After success, the handler invokes the Confirmation sender, which calls the external Email provider.

An engineer changing the opening-hours rule can see the code responsibility without reading a request timeline. The sketch hides the number of API processes and the exact order of database statements. "Reservation service" is a code unit here; it is not another deployed service. If you draw it as a separate server merely because it has "service" in its name, the diagram tells the wrong story.

Deployment view: where does the software run?

Conceptual deployment view, one region
Customer and staff browsers -- HTTPS --> Booking API process on app host
Booking API process -- database connection --> Booking DB on managed database host
Booking API process -- provider API call --> external Email provider

The Booking API code runs as one process on an app host in this simplified deployment. The Booking DB is hosted separately. The Email provider remains outside Harbor Cuts. Here an arrow identifies a connection between running locations, not a call between code modules or an ordered step in one booking. This view gives an operator a place to ask about network access, credentials, backups, and what happens when the app host fails.

It does not tell the operator how much traffic the host can handle. A line between the API and database says nothing about latency, query cost, connection limits, or capacity. Those claims need configuration, load data, and measurement. Stephany Bellomo's SEI report adapts the Views and Beyond approach to service-oriented systems; it is documentation guidance, not evidence that any deployment drawing proves performance.

Move confirmation delivery out of the request

Suppose customers should see a confirmed booking without waiting for the Email provider. Harbor Cuts changes the design: the Booking API writes both the booking and a pending confirmation record to the Booking DB in one transaction. It returns the booking ID after that commit. A new Confirmation worker reads pending records and calls the Email provider later.

The context view stays the same. Customers, staff, the booking service, and the Email provider still have the same relationships. An internal timing change does not create a new external actor.

The runtime view changes substantially. The Booking API no longer calls the provider on the customer's path. After it commits and responds, the Confirmation worker reads a pending record, requests delivery, and marks that record submitted when the provider accepts the request. Provider acceptance does not prove that the email reached the customer. The two time periods should be visible as separate paths. A failed provider call now delays an email without making the booking request fail.

The module view changes at the ownership boundary. The Reservation service must ask the Appointment repository to write the pending confirmation alongside the booking in the same database transaction. A worker module takes over invoking the Confirmation sender. The Opening-hours policy retains its original concern. This is a change to code responsibilities, not merely another arrow in the request sequence.

The deployment view gains a worker process connected to the Booking DB and Email provider. The existing app host and database may remain, but the team now has to decide where the worker runs, how it restarts, and how to observe a growing pending backlog. The drawing alone cannot answer whether the revised design meets a response-time target.

There is a new failure case as well. A worker can submit an email and crash before marking the record submitted, then submit it again on retry. Harbor Cuts must either use a provider feature that prevents duplicate sends or accept and handle that possibility. Moving work later changes the failure story; it does not make delivery automatically reliable.

The useful habit is to keep the names stable while changing what each arrow means. When a review question concerns the customer boundary, open the context view. When it concerns the timing of a booking, follow the runtime path. When it concerns who edits a rule or where a process fails, use the module or deployment view. You can use Lycana to speak or type a focused view and revise its components and relationships as the question changes. Keep each view's meaning clear; an editable diagram does not establish that the code, configuration, or measured behavior matches it.