Contact Us

If you still have questions or prefer to get help directly from an agent, please submit a request.
We’ll get back to you as soon as possible.

Please fill out the contact form below and we will reply as soon as possible.

  • Contact Us
  • Home
  • System Architecture

Answers to Exercise Questions

Written by Oleksandr Sydorenko

Updated at May 5th, 2025

Contact Us

If you still have questions or prefer to get help directly from an agent, please submit a request.
We’ll get back to you as soon as possible.

Please fill out the contact form below and we will reply as soon as possible.

  • System Architecture
+ More

Chapter 1

1. D: B and C. Only core subdomains provide competitive advantages that differen‐ tiate the company from other players in its industry.

2. B: Generic. Generic subdomains are complex but do not entail any competitive advantage. Hence, it’s preferable to use an existing, battle-proven solution.

3. A: Core. Core subdomains are expected to be the most volatile since these are areas in which the company aims to provide new solutions and it often requires quite a few interactions to find the most optimized solution.

4. WolfDesk’s business domain is Help Desk management systems.

5. We can identify the following core subdomains that allow WolfDesk to differenti‐ ate itself from its competitors and support its business model:

a. Ticket lifecycle management algorithm that is intended to close tickets and thus encourage users to open new ones

b. Fraud detection system to prevent abuse of its business model

c. Support autopilot that both eases the tenants’ support agents’ work and fur‐ ther reduces the tickets’ lifespan

6. The following supporting subdomains can be identified in the description of the company:

a. Management of a tenant’s ticket categories

b. Management of a tenant’s products, regarding which the customers can open support tickets

c. Entry of a tenant’s support agents’ work schedules

7. The following generic subdomains can be identified in the description of the company:

a. “Industry standard” ways of authenticating and authorizing users

b. Using external providers for authentication and authorization (SSO)

c. The serverless compute infrastructure the company leverages to ensure elastic scalability and minimize the compute costs of onboarding new tenants

Chapter 2

1. D: All of the project’s stakeholders should contribute their knowledge and under‐ standing of the business domain.

2. D: A ubiquitous language should be used in all project-related communication. The software’s source code should also “speak” its ubiquitous language.

3. WolfDesk’s customers are tenants. To start using the system, tenants go through a quick onboarding process. The company’s charging model is based on the num‐ ber of tickets that were opened during a charging period. The ticket lifecycle man‐ agement algorithm ensures that inactive tickets are automatically closed. WolfDesk’s fraud detection algorithm prevents tenants from abusing its business model. The support autopilot functionality tries to find solutions for new tickets automatically. A ticket belongs to a support category and is associated with a prod‐ uct for which the tenant provides support. A support agent can only process tick‐ ets during their work time, which is defined by their shift schedules.

Chapter 3

1. B: Bounded contexts are designed, while subdomains are discovered.

2. D: All of the above. A bounded context is a boundary of a model, and a model is only applicable in its bounded context. Bounded contexts are implemented in independent projects/solutions, thus allowing each bounded context to have its own development lifecycle. Finally, a bounded context should be implemented by a single development team, and therefore, it is also an ownership boundary.

3. D: It depends. There is no perfect size of a bounded context for all projects and cases. Different factors, such as models, organizational constraints, and nonfunc‐ tional requirements, affect the optimum scope of a bounded context.

4. D: B and C are correct. A bounded context should be owned by one team only. At the same time, the same team can own multiple bounded contexts.

5. It’s safe to assume that the operation model, implementing the tickets’ lifecycle, will be different from the one used for fraud detection and the support autopilot feature. Fraud detection algorithms usually require more analytics-oriented

modeling, whereas, the autopilot feature is likely to use a model optimized for use with machine learning algorithms.

Chapter 4

1. D: Separate ways. The pattern entails duplicate implementation of a functionality in multiple bounded contexts. Duplicating complex, volatile, and business- critical business logic should be avoided at all costs.

2. A: Core subdomain. A core subdomain is most likely to leverage an anticorrup‐ tion layer to protect itself from ineffective models exposed by upstream services, or to contain frequent changes in the upstream’s public interfaces.

3. A: Core subdomain. A core subdomain is most likely to implement the open- host service. Decoupling its implementation model from the public interface (published language) makes it more convenient to evolve the core subdomain’s model without affecting its downstream consumers.

4. B: Shared kernel. The shared kernel pattern is an exception to the bounded con‐ texts’ single team ownership rule. It defines a small portion of the model that is shared and can be evolved simultaneously by multiple bounded contexts. The shared part of the model should be always kept as small as possible.

Chapter 5

1. C: Neither of these patterns can be used to implement a core subdomain. Both transaction script and active record lend themselves to the case of simple busi‐ ness logic, whereas core subdomains involve more complex business logic.

2. D: All of the above issues are possible:

a. If the execution fails after line 6, the caller retries the operation, and the same agent is chosen by the FindLeastBusyAgent method, the agent’s ActiveTickets counter will be increased by more than 1.

b. If the execution fails after line 6 but the caller doesn’t retry the operation, the counter will be increased, while the ticket itself won’t be created.

c. If the execution fails after line 12, the ticket is created and assigned, but the notification on line 14 won’t be sent.

3. If the execution fails after line 12 and the caller retries the operation and it suc‐ ceeds, the same ticket will be persisted and assigned twice.

4. All of WolfDesk’s supporting subdomains are good candidates for implementa‐ tion as transaction script or active record as their business logic is relatively straightforward:

a. Management of a tenant’s ticket categories

b. Management of a tenant’s products, regarding which the customers can open support tickets

c. Entry of a tenant’s support agents’ work schedules

Chapter 6

1. C: Value objects are immutable. (Also, they can contain both data and behavior.)

2. B: Aggregates should be designed to be as small as possible, as long as the busi‐ ness domain’s data consistency requirements are intact.

3. B: To ensure correct transactional boundaries.

4. D: A and C.

5. B: An aggregate encapsulates all of its business logic, but business logic manipu‐ lating an active record can be located outside of its boundary.

Chapter 7

1. A: Domain events use value objects to describe what has happened in the busi‐ ness domain.

2. C: Multiple state representations can be projected and you can always add addi‐ tional projections in the future.

3. D: Both B and C are correct.

4. The ticket lifecycle algorithm is a good candidate to be implemented as an event- sourced domain model. Generating domain events for all state transitions can make it more convenient to project additional state representations optimized for the fraud detection algorithm and the support autopilot functionality.

Chapter 8

1. D: A and C.

2. D: B and C.

3. C: Infrastructure layer.

4. E: A and D.

5. Working with multiple models projected by the CQRS pattern doesn’t contradict the bounded context’s requirement of being a model boundary, since only one of the models is defined as the source of truth and is used for making changes in the aggregates’ states.

Chapter 9

1. D: B and C.

2. B: Reliably publish messages.

3. The outbox pattern can be used to implement asynchronous execution of exter‐ nal components. For example, it can be used for sending email messages.

4. E: A and D are correct.

Chapter 10

1. Event-sourced domain model, CQRS architecture, and testing strategy that focu‐ ses on unit tests.

2. The shifts can be modeled as active records, working in the layered architectural pattern. The testing strategy should primarily focus on integration tests.

3. The business logic can be implemented as a transaction script, organized in a lay‐ ered architecture. From a testing perspective, it’s worth concentrating on end-to- end tests, verifying the full integration flow.

Chapter 11

1. A: Partnership to customer–supplier (conformist, anticorruption layer, or open- host service). As an organization grows, it can become more challenging for teams to integrate their bounded contexts in an ad hoc fashion. As a result, they switch to a more formal integration pattern.

2. D: A and B. A is correct because bounded contexts go separate ways when the cost of duplication is lower than the overhead of collaboration. C is incorrect because it’s a terrible idea to duplicate implementation of a core subdomain. Consequently, B is correct because the separate ways pattern can be used for sup‐ porting and generic subdomains.

3. D: B and C.

4. F: A and C.

5. Upon reaching a certain level of growth, WolfDesk could follow the footsteps of Amazon and implement its own compute platform to further optimize its ability to scale elastically and optimize its infrastructure costs.

Chapter 12

1. D: All stakeholders having knowledge of the business domain that you want to explore.

2. F: All the answers are sound reasons to facilitate an EventStorming session.

3. E: All the answers are possible outcomes of an EventStorming session. The out‐ come you should expect to get depends on your initial purpose for facilitating the session.

Chapter 13

1. B: Analyze the organization’s business domain and its strategy.

2. D: A and B.

3. C: A and B.

4. An aggregate with a bounded context-wide boundary may make all of the boun‐ ded context’s data a part of one big transaction. It’s also likely that performance issues with this approach will be evident from the get go. Once that happens, the transactional boundary will be removed. As a result, it will no longer be possible to assume that the information residing in the aggregate is strongly consistent.

Chapter 14

1. A: All microservices are bounded contexts. (But not all bounded contexts are microservices.)

2. D: The knowledge of the business domain and its intricacies exposed across the service’s boundary and reflected by its public interface.

3. C: Boundaries between bounded contexts (widest) and microservices (narrowest).

4. D: The decision depends on the business domain.

Chapter 15

1. D: A and B are correct.

2. B: Event-carried state transfer.

3. A: Open-host service.

4. B: S2 should publish public event notifications, which will signal S1 to issue a synchronous request to get the most up-to-date information.

Chapter 16

1. D: A and C are correct.

2. B: Open-host service. One of the published languages exposed by the open-host service can be OLAP data optimized for analytical processing.

3. C: CQRS. The CQRS pattern can be leveraged to generate projections of the OLAP model out of the transactional model.

4. A: Bounded contexts.

Was this article helpful?

Yes
No
Give feedback about this article

Related Articles

  • Discovering Domain Knowledge
  • Business Problems
  • Knowledge Discovery
  • Communication
  • What Is a Ubiquitous Language?

info@smartphonekey.com

  • Home
  • How It Works
  • Features
  • Residents and Tenants
  • Property Managers
  • Airbnb Hosts
  • Products
  • Blog
  • Guide for Usage and Installation
  • Our Team
  • Contact Us
  • Privacy Policy
  • Terms of Service
  • Facebook
  • Instagram
  • LinkedIn
© 2025, Smartphonekey.com Powered by Shopify
Expand