Responsibilities and Boundaries

Three details in that code do the hiding. First, the table stores sold_out, but the interface returns is_available, so Menu can rename or replace the column without any caller noticing. Second, get_item returns a MenuItem object instead of a database row, so callers cannot depend on columns that the interface does not list. Third, the connection is private: in Python the leading underscore on _db marks it as private by convention, and the other languages declare the field private or unexported. Orders now calls menu.get_item(42).price_cents, and the repair for Sign 3 is complete. The third operation, list_items, follows the same pattern and is left out to keep the example short.

Part 5: Two Ways to Split a System

Once each responsibility has an owner, the code still has to be arranged into parts. There are two common ways to draw the main boundaries: by technical job or by business area.

A split by technical job produces layers. The presentation layer receives requests and formats responses for all three client apps. The business logic layer holds the rules for orders, menus, payments and every other area. The data access layer reads and writes every table in the PostgreSQL database. The folders are controllers/, services/ and repositories/, and each one contains code for every business area. The Layered (N-Layer) Architecture lesson teaches this split in depth.

A split by business area produces modules. The folders are orders/, menu/, payments/, dispatch/, notifications/ and accounts/. Each module contains its own request handling, its own rules and its own data access, and it owns its own tables in the shared database. When this split is deployed as one application, it is a modular monolith, which the Monolith Architecture lesson describes in detail.

The diagram below shows the same food-delivery backend split both ways, with four of the six business areas drawn. The Menu code is outlined: on the left it is cut across three layers, and on the right it sits inside one module.

Each split makes a different kind of change local. Consider two requests that arrive in the same week.

The first request lets restaurants mark an item as sold out for the rest of the day. In the layered split, the change touches controllers/, services/ and repositories/. Those are three folders, which may belong to three different teams. In the modular split, every edit stays inside menu/.

The second request adds a 2-second timeout to every database query. In the layered split, the change sits in one place, the data access layer. In the modular split, it touches six modules, unless the team has already moved database access into a shared library.

The table below compares the two splits.

Most systems combine the two. They split by business area at the top level of the code and use layers inside each module, so orders/ holds its own controllers, rules and repositories. The Microservices Architecture lesson keeps the business-area split and places each module in a service of its own.

Part 6: Boundaries Inside One Deployable and Across the Network

A boundary can sit between modules inside one deployable artifact, or between services that talk over the network. The interface can look identical in both cases, but crossing the boundary costs very different amounts.

A module boundary is crossed with a function call. Both sides run in the same program, so the call itself from Orders to Menu adds well under a microsecond. Both sides also fail together, and one database transaction can cover writes made by both modules. The boundary is enforced by convention, by code review, and by tools that fail the build when one module imports another module's internals. A single wrong import can cross it, but moving it is one refactor in one pull request.

A service boundary is crossed with a network call. A call between two services in one data center typically takes roughly 0.5 to a few milliseconds once serialization (converting the data to bytes) is included. Either side can also fail while the other keeps running. The caller therefore needs timeouts and retries, and no single database transaction covers both sides. The boundary is enforced by the network itself, because Orders has no connection to Menu's database. Moving it means changing an API, migrating data and coordinating releases of two services.

Checkout in the food-delivery app shows the difference with numbers. It crosses four boundaries: Menu for prices, Accounts for the delivery address, Payments for the charge, and Dispatch to request a courier. As modules, the four crossings are function calls that add well under 1 ms in total. As services called one after another at an illustrative 3 ms each, they add about 12 ms, plus code to handle each one failing. Availability also changes. Suppose each of the four services is available 99.9 percent of the time and failures are independent. All four calls then succeed 0.999 to the fourth power, or about 99.6 percent, of the time, so checkout fails about four times as often as any one service does. The Quality Attributes lesson in this chapter explains how such numbers are measured.

The practical order follows from that table. Draw boundaries as modules first, because a module boundary in the wrong place is cheap to move. Watch how each boundary behaves as the product changes. A module boundary that has stayed the same for many months is a candidate for a service boundary, if a specific need justifies the cost. Separate releases are such a need, and so is a scaling need that cannot be met by running part of the same application on machines of its own. A boundary that keeps changing should stay a module. The Monolith Architecture lesson's section on extracting services describes the signals that justify that step.

FAQs

Q: Is a responsibility the same as the single responsibility principle?

They are the same idea at different sizes. The single responsibility principle says that a class should have only one reason to change. This lesson applies the same test to whole components, so one component with one responsibility can still contain dozens of classes.

Q: How large should a module be?

There is no fixed line count. A module should cover one business capability that one team can own and explain in one sentence. If two modules always change together, consider merging them; if one module has three reasons to change, consider splitting it.

Q: Who owns data that many components need, such as a customer's address?

Exactly one component owns it, and in the food-delivery app that owner is Accounts. Other components ask Accounts through its interface or keep a read-only copy that they refresh when Accounts announces a change. Orders does store the address on each order, but that copy is a record of where this order went, so it belongs to Orders.

Q: Is a layer the same as a tier?

No. A layer is a way of organizing code, and several layers usually run inside one program. A tier is a part of the system that runs on its own machines and talks to the other parts over the network. The N-Tier Architecture lesson covers tiers in full.

Q: Can a client app hold a business rule?

A client app may repeat a rule to give faster feedback. For example, the Customer app can show "minimum order $10" before the customer taps the order button. The backend component still owns the rule and checks it again, because an old app version or a modified app could send any request.

Key Takeaways

• A responsibility is a job with its data and its decisions. A component that does the work but asks another component for every decision does not own the job.
• State each responsibility in one sentence. If the sentence needs an "and" between unrelated jobs, or names another component's data, the responsibility is assigned badly.
• Three signs show a misplaced responsibility: one component with several unrelated jobs, one job spread across several components, and two components that always change together.
• Separation of concerns applies between components, not only within the code for one request. A requirement that belongs to one concern should touch one component.
• A boundary hides; an interface promises. Keep the interface much smaller than what it hides, because every item in it is something the owner can no longer change alone.
• Splitting by technical job gives layers; splitting by business area gives modules. Layers make technical changes local, modules make feature changes local, and most systems use modules at the top level with layers inside each one.
• A module boundary is cheap to cross and cheap to move; a service boundary is neither. A network crossing adds milliseconds and new failures, and moving a service boundary needs API changes and data migration.
• Draw boundaries as modules first. Turn a module into a service only when its boundary has not changed for months and a specific need justifies the cost.

The next lesson in this chapter, Coupling, Cohesion, and Dependencies, measures how strongly the components drawn here depend on one another. It also shows which way those dependencies should point.