Follow Amina as she looks for a product Daniel has prepared. We use their story to decide where a business responsibility belongs. The diagrams show a possible design. No ClearLend microservices application has been built.
Teaching chapter · Fictional example · Design only
01 / Where we start
A person comes before a service.
The course foundation asks us to understand a person's goal before choosing tools. Amina is a fictional borrower. She wants to read a lender product before deciding what to do next. Daniel is a fictional lender. He prepares the product terms. Their names and roles help us discuss the design; they are not real customers or users of a running system.
A service boundary is a line around one set of business responsibilities. Before drawing that line, we need to know which facts must stay together and who may change or read them. We are not choosing a database, API gateway or cloud platform in this chapter.
Our question
When Daniel changes a draft, how do we make sure Amina sees only the approved public version?
02 / Follow the person
What should Amina see?
Daniel prepares example product terms. They are a draft, so Amina cannot see them.
In our fictional story, the product is approved for publication. The exact approval rule would need a product owner to define it.
Amina opens the product list and chooses one product.
She sees the published terms and a version number. A version identifies the particular set of terms she read.
If the product is missing or still a draft, she sees a clear “not available” message. She does not see private draft text.
A proposed journey. The arrows show decisions a future system would make; they are not calls to a running application. On a phone, swipe the diagram to read it.
The success path and failure path both matter. If we draw only the happy path, we might accidentally allow a draft into the public list.
03 / Name the facts
Who gives the official answer?
A business fact is information the business relies on. Here the key facts are the product's draft terms, its publication state, and the public terms and version. Ownership means one part of the future system gives the official answer for each fact. Another part may display that answer, but should not quietly make a second copy into a new authority.
Fact
Proposed owner
Who needs it?
Why?
Draft product terms
Product Catalog
Daniel and a future reviewer
Amina must not see unfinished terms.
Publication state
Product Catalog
Daniel, reviewer and Amina's product view
One decision says whether terms are public.
Published terms and version
Product Catalog
Amina
She should know which terms she saw.
Amina's future application draft
Applications, as a later proposal
Amina
Her application is a different business fact.
This is a responsibility map. It does not claim that a Catalog service or database exists. On a phone, swipe the diagram to read it.
04 / Compare choices
Should Catalog be a separate microservice yet?
A microservice is a separately managed part of a system with a useful business responsibility and clear ownership. It brings more than a new project folder: another deployment, network communication, monitoring and failure cases.
Choice
What it helps
What it costs
One well-organised application
Simple to change and explain while the product rules are still being learned.
Catalog cannot be released on its own.
A separate Catalog service
Could give a team independent control over product publication and releases.
Needs a network contract, its own operations and a way to handle failures.
Our design decision: treat Product Catalog as a proposed business boundary, but do not claim it must be a separate service. First check whether its rules and changes truly need independence from Applications. A single organised application could be the better start.
The tradeoff is clear: we delay independent deployment, while avoiding distributed complexity before the story needs it. Later chapters can revisit this choice when Amina starts an application and Daniel changes a product.
05 / Check your understanding
Can you explain the decision?
Imagine Daniel changes a draft after Amina has read version 1. Ask yourself: should her earlier view silently change? Which part of the future design knows what was published at that time? The version is useful because it lets us name the public terms she saw. How an application later records that version belongs to another chapter.
Common mistake
Drawing one service for every screen or table. A product list and product detail may be two screens, but they still use the same published-product facts. Splitting them would add communication without a useful business reason.
Practical checklist
Can you state Amina's goal in one sentence?
Can you say which terms Daniel may prepare and which terms Amina may see?
Can you identify one proposed owner for publication state and version?
Can you describe both the published and unavailable results?
Can you explain why a separate service may help later and what it would cost?
Can you point to what remains a proposal, rather than a working system?
How I would explain it in an interview
“I began with a borrower reading a lender product. The risk was showing a private draft or losing track of published terms. I proposed one Catalog owner for publication state and versions. I would keep the first design simple and only split Catalog into a separate service when independent change and operation justify the extra cost.”
Where the story goes next
Amina may want to save an application draft. That new fact needs its own rules and owner. Stage 2 will explore the design, with diagrams and plain explanations. It is still coming soon.
Course status Stage 1 is a teaching chapter. No ClearLend API, database, container, cloud resource or reference application is supplied.
