Which module calls the payment provider directly?

The Payment Module. Only from there an arrow leads to the payment provider; order commissions the payment, but does not speak to the provider itself.

In the future, the shop will also sell vouchers with its own price. In which module does this change land first?

In the catalogue, because he is responsible for products and prices. Shopping cart and order read the prices only and remain unchanged in their structure.

The team considers that ordering calls the payment provider directly. What speaks against it?

Then there would be knowledge about the provider in order and in payment. A change of provider would affect several modules; today, payment encapsulates the provider alone. How to record such decisions shows architectural decision.

ConceptChapter I · Fundamentals · Building block 1 of 7

Software architecture

Software architecture is the basic structure of a system: its important building blocks, its relationships and the decisions why it is built this way. It determines how well the system can be changed, operated and extended.

By Michael Meierhoff · Meierhoff Systems

Building blocksShare with a clear task.
RelationshipsWho calls or knows whom.
DecisionsWhy it's built this way.

Context

Why this is important

Architecture is what is expensive to change later: the rough division and the basic decisions. Details within a module can usually be corrected more easily. How you justify decisions and set quality goals deepen your own building blocks.

This is about the big picture. How you answer individual questions with suitable representations shows architectural views.

At a glance · Architecture of building blocks and decisions

Requirements drive decisions, and these shape the structure of building blocks and their relationships.

Shop example · Building blocks and relationships

Architecture of the modular shop

The shop is a modular monolith: a single application, internally divided into seven modules – catalogue, shopping cart, order, payment, warehouse, shipping and invoice. The payment provider is a foreign system outside the shop.

This is how you read the picture

Building blocks The boxes: seven modules and the payment provider.
Relationships The arrows, for example order → payment.
Decisions Only payment talks to the payment provider; all modules run in one application.

Wide diagram · Move laterally if necessary

Read diagram as text

Catalogue: Products and prices (Shop application)
Basket: Selection of the customer (Shop application)
Order: Mission and status (Shop application)
Payment: Payment instruction (Shop application)
Inventory: Reservation (Shop application)
Shipping: Consignment (Shop application)
Invoice: Evidence (Shop application)
Payment provider: Authorisation (External)

Basket → Catalogue: Reads product data
Basket → Order: Create an order
Order → Payment: Request for payment
Payment → Payment provider: Authorisation
Order → Inventory: Stock Reserve
Order → Shipping: Releases paid order
Order → Invoice: Create an invoice

Building block view: Each arrow is a call from the source to the target; the response runs back via the same call. Further calls between the modules are not provided. Order coordinates payment, storage, shipping and invoice. Other actors show the system context.

Benefits & limitations

Helps if:

Several people work on the same system and have to coordinate on responsibilities and dependencies.
A change, such as adding a payment provider, affects several modules or quality goals such as security and modifiability.

Boundaries

Architecture defines boundaries and relationships rather than the implementation of every function; the team chooses variable names in the code.
The description becomes outdated when the code diverges. Compare it regularly with the Module Boundaries and runtime behaviour.
A single representation shows only part of the system; other questions require additional Architecture Views.

In practice

Identify the scope. Read existing descriptions and state which system or part of it they cover and which responsibility they focus on. See System Context and Boundary for a structured description of users and neighbouring systems.
Organise the main parts and their relationships. Describe responsibilities and the permitted interactions between them. Where useful, link the view to System Context and Boundary to distinguish internal responsibilities from external dependencies.
Identify existing structural choices and their effects. Record which boundaries and relationships already apply and how they influence further development. Comparing options and making a decision belong to Architectural Decisions.

Read the detailed explanation

Each module in the shop has a responsibility: Catalogue manages products and prices; Payment handles payments. Architecture describes the boundaries between these parts, which part calls which, and the reasons for those decisions. It covers both structure and interaction at runtime.

Architectural decisions connect a chosen structure to its rationale and expected consequences. A description is easier to understand when it states its scope and uses an appropriate perspective. System Context and Boundary clarifies the scope; Architecture Views provides perspectives for specific questions.

ISO/IEC/IEEE 42010 describes the contents of an architecture description: stakeholders, their concerns, views and the rationale for decisions.

Check your understanding

Test yourself in three stages

ReadingCheck in the picture
Which module calls the payment provider directly?
View the solution with justification
The Payment Module. Only from there an arrow leads to the payment provider; order commissions the payment, but does not speak to the provider itself.
ApplyingTransferred to a new situation
In the future, the shop will also sell vouchers with its own price. In which module does this change land first?
View the solution with justification
In the catalogue, because he is responsible for products and prices. Shopping cart and order read the prices only and remain unchanged in their structure.
EvaluateWeighing an alternative
The team considers that ordering calls the payment provider directly. What speaks against it?
View the solution with justification
Then there would be knowledge about the provider in order and in payment. A change of provider would affect several modules; today, payment encapsulates the provider alone. How to record such decisions shows architectural decision.

Explore further

These building blocks continue the thoughts of this page.

References

Continue on the learning path

Next in Fundamentals & orientation: System context & system boundary.

7 Building blocks

Continue withSystem context & system boundary