Learn vocabulary for bounded contexts, ubiquitous language, and domain-driven design communication.
0 / 10 completed
1 / 10
What is a 'bounded context' in Domain-Driven Design vocabulary?
Bounded context (Eric Evans, DDD): a boundary within which a single, consistent domain model applies. The same word may mean different things in different bounded contexts: 'Customer' in Sales BC (prospect + active customer) vs. 'Customer' in Support BC (anyone who has ever purchased). Bounded contexts make these differences explicit.
2 / 10
What is 'ubiquitous language' in DDD vocabulary?
Ubiquitous language: developers and domain experts use the same vocabulary everywhere — in code (class names, method names), in conversations, in documentation. If the business says 'Order' and the code says 'PurchaseRecord', there is a translation layer that adds confusion. The goal: eliminate translation between business language and code.
3 / 10
What is a 'context map' in DDD vocabulary?
A context map documents the relationships between bounded contexts: Upstream/Downstream (U produces the model, D adapts to it), Customer/Supplier (supplier commits to the customer's needs), Conformist (downstream simply conforms to upstream), Anti-Corruption Layer (downstream translates upstream model to protect its own model). Context maps prevent hidden coupling.
4 / 10
What is an 'anti-corruption layer' (ACL) in microservices vocabulary?
Anti-Corruption Layer: when integrating with an external system or legacy system whose model differs from yours, the ACL translates at the boundary. Your service works with its own clean model; the ACL handles translation to/from the external model. This prevents external model concepts from 'leaking' into and corrupting your domain model.
5 / 10
What is 'domain event' vocabulary in microservices communication?
Domain events: 'OrderPlaced', 'PaymentReceived', 'InventoryReserved'. They record facts in the past tense — something that happened. Other bounded contexts subscribe to events they care about and react in their own domain model. Domain events enable loose coupling: the publishing context doesn't know or care who is listening.
6 / 10
Code Review Comment: 'The `OrderService` seems to be handling address validation. Shouldn't this be done in the `CustomerContext'? This feels like a potential violation of the bounded context.' What does this comment primarily highlight regarding Bounded Contexts?
This comment is focused on the risk of coupling between services. Bounded Contexts aim to isolate responsibilities; sharing address validation logic suggests a lack of clear boundaries and potential for inconsistencies. Option A discusses testing, which is related but not the core issue being raised here. Options C and D are broader concerns about data management that aren't directly addressed in the comment.
7 / 10
Slack Message: 'Hey @john.doe, just wanted to clarify – the 'Payment' bounded context is solely responsible for processing transactions and doesn't involve any user profile data. We shouldn't be pulling information from the 'UserContext' here.' What does this Slack message illustrate about a Bounded Context?
This Slack message demonstrates the core principle of bounded contexts – that each has its own specific domain and shouldn't be overly reliant on other contexts. The conversation highlights the separation of concerns by explicitly stating what the 'Payment' context *doesn't* handle, reinforcing its independent scope. Options A, C, and D represent broader architectural patterns or optimization strategies, not the definition of a bounded context itself.
8 / 10
API Response: The following JSON response represents an event emitted by the 'Inventory' bounded context:
What is the significance of this response within a Domain-Driven Design context?
Domain events are crucial in DDD. This response signifies a state change within the 'Inventory' bounded context. These events are not about direct database updates or HTTP requests; instead, they trigger reactions and processes in *other* contexts that might be interested in this inventory shift – forming the basis for asynchronous communication and looser coupling.
9 / 10
PR Description: 'Implementing an ACL to prevent direct modifications to the 'Product' bounded context from the 'CustomerService'. This layer will translate requests and enforce invariants related to product attributes, ensuring data integrity within the Product domain.' What is the primary purpose of this Anti-Corruption Layer (ACL) in relation to Bounded Contexts?
An ACL is designed to protect a bounded context from external influence. The goal is to isolate the 'Product' context and prevent changes that might violate its defined rules – ensuring consistency and preventing corruption of data within that specific domain. This is about controlled access and rule enforcement, not general optimization or error handling.
10 / 10
Standup Update: 'I'm working on the new order processing system. The 'OrderContext' is now actively publishing domain events whenever an order status changes, and the 'ShippingContext' subscribes to these events to update shipment tracking.' What does this exemplify regarding Bounded Contexts and communication?
This describes asynchronous communication driven by domain events. This is a core DDD pattern that allows bounded contexts to react to changes in other contexts without direct dependencies or tight coupling. This approach promotes loose coupling and better responsiveness – the key benefit of using bounded contexts.
What will I practise in "Bounded Context — Domain-Driven Design Vocabulary"?
This module focuses on Microservices Language — real workplace phrasing you'll use on the job. It contains 10 scenario-based multiple-choice questions with instant feedback.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account or sign-up required.
How many questions does this exercise have?
This module includes 10 questions. Each one gives an immediate right/wrong result plus a full explanation of the correct phrasing.
What happens if I answer a question incorrectly?
You'll see the correct answer highlighted straight away, along with a plain-English explanation of why it's right and why the other options don't fit — mistakes are part of the learning here.
Can I retry the exercise if I want a better score?
Yes — use the 'Try again' button on the results screen to reset your score and go through the questions again. There's no limit on attempts.
Who is this Microservices Language exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around microservices language — useful whether you're preparing for real conversations at work or just building confidence with the vocabulary.
Do I need an account to track my progress?
No account is needed. Your progress through the exercise is tracked locally in your browser for the current session, and you can replay the module at any time.
How is this different from reading a blog article?
This exercise is an interactive drill that tests and reinforces specific phrasing through multiple-choice questions with instant feedback, while blog articles explain concepts and vocabulary in prose. The two work well together.
Where can I find more Microservices Language exercises?
See the Microservices Language hub for more modules like this one, or browse the full Exercises page for other IT-English topics.
Can I complete this exercise on my phone?
Yes — every exercise on CoderSlingo is fully responsive and works on phones and tablets, so you can practise anywhere.