Who writes the order status in the shop database?

Write the order module via the edge “Status transition”. Shipping module and reports do not write.

After dispatch, B-1042 shall be considered as ‘consigned’. How is the change going?

The shipping module reports a shipping event to the ordering module. This checks the allowed transition and writes the new status into the database.

The shipping module writes the status itself for simplification. What is the advantage and risk of this?

It saves the detour through the event. This bypasses the transition rules of the ordering module, and changes to the status field then affect several modules.

Standalone conceptRiskChapter II · Data · Building block 15 of 16

Shared database

A shared database is used by several modules or services. Common tables can pair changes, permissions, and error sequences across these boundaries.

By Michael Meierhoff · Meierhoff Systems

WritersExactly one owner changes the status.
ReadersOthers use a contract.
EventChange request instead of direct access.

Context

Why this is important

The modular shop deliberately uses a shared database for local transactions and shared operations. Clear writers preserve business rules. Independent services must additionally examine whether shared schemas couple their deployment.

Here you compare the benefits and coupling of shared data storage. Database per Service describes the alternative for autonomous services.

At a glance · Common Database as coupling

Hypothetical failure variant: two independent services write to the same table and couple their schema changes. The modular shop instead uses clear write ownership.

Shop example · Building blocks and relationships

Writing authority for the order status

In the shop, several modules read order data; the order module remains the sole scribe of the order status. Shipping reports changes through a module contract.

This is how you read the picture

Writers Box “Order module”: has status and transition rules, arrow “Write status transition” to the “Shop database”.
Readers Box “Reports” with arrow “Request status view” to the order module.
Event Arrow ‘Report shipping event’ from ‘shipping module’ to ‘order module’.

The shop modules remain in the modular monolith; a business owner controls status transitions.

Benefits & limitations

Helps if:

Shared transactions and queries benefit from clear responsibility for data and schema.
Modules deployed together benefit from local transactions and manageable database operations as long as write permissions and schema ownership remain clear.

Boundaries

Unknown readers can make schema changes fail; inventory access and choose transitions with a clear retirement criterion. See Data migration.
Common locks and loads couple runtime behaviour; measure competing workloads and separate them when bottlenecks occur.
For independently deployable services, a shared schema can couple changes; assess this specific boundary against Database per Service.

In practice

Inventory access and data areas. Record readers, writers, jobs and migrations for each table and schema. Link each access to a business responsibility. This produces a traceable coupling map.
Define write ownership. Identify the building block that controls the rules and changes for a business fact. Restrict other components’ direct write permissions and document permitted read contracts. This makes the authoritative data path clear.
Control changes and load. Test schema changes with known consumers and observe locks, pools and recovery. Plan a gradual transition with a measurable completion criterion. This supports safe handling of coupling and transition.

Read the detailed explanation

A shared database is a database used by several components. In a modular monolith this can be a deliberate long-term decision: shared transactions and manageable operations fit a shared deployment. Separate schemas and clearly assigned write permissions preserve business data ownership.

Shared tables, locks, resources and schema changes couple their users. For independently deployable services, this coupling can limit autonomy. Database per Service encapsulates data access behind the service contract, at the cost of additional cross-boundary queries and coordination. The choice follows transaction needs, team ownership and operational goals.

In the existing shop, Order remains the sole writer of its status. Other modules use agreed access paths; the shared database server makes them neither independent services nor a distributed monolith. A later separation requires verifiable data migration.

Check your understanding

Test yourself in three stages

ReadingCheck in the picture
Who writes the order status in the shop database?
View the solution with justification
Write the order module via the edge “Status transition”. Shipping module and reports do not write.
ApplyingTransferred to a new situation
After dispatch, B-1042 shall be considered as ‘consigned’. How is the change going?
View the solution with justification
The shipping module reports a shipping event to the ordering module. This checks the allowed transition and writes the new status into the database.
EvaluateWeighing an alternative
The shipping module writes the status itself for simplification. What is the advantage and risk of this?
View the solution with justification
It saves the detour through the event. This bypasses the transition rules of the ordering module, and changes to the status field then affect several modules.

Explore further

These building blocks continue the thoughts of this page.

References

Continue on the learning path

Next in Data & state: Change Data Capture.

16 Building blocks

Continue withChange Data Capture