Microservice Architecture and Domain-Driven Design

Introduction

Microservices are an architectural approach in which an application is organized as a set of independently deployable services. Each service implements a coherent business capability, owns a defined portion of the system’s data and behaviour, and communicates with other services through explicit interfaces. Microservices are not simply a method of splitting a large codebase into smaller programs. They are an organizational, technical and architectural response to the problems of scale, change, team autonomy and system complexity.

Domain-Driven Design (DDD) provides a disciplined way to decide where service boundaries should be placed. Rather than beginning with technical layers such as databases, user interfaces or infrastructure, DDD begins with the business domain: the set of activities, rules, terminology and goals that define an organization’s area of operation. The central design challenge is to discover boundaries that are meaningful to the business and sustainable in software.

A poorly decomposed microservice system can be more difficult to operate than a modular monolith. Excessive service-to-service calls, duplicated business rules, distributed transactions and unclear ownership produce what is sometimes called a distributed monolith: a system deployed as multiple services but coupled as tightly as a single application. Effective decomposition therefore requires analysis of domains, subdomains, bounded contexts, dependencies, team ownership and expected future change.

Learning Objectives

By the end of this chapter, students should be able to:

1. Explain the relationship between domains, subdomains, bounded contexts and microservices.
2. Distinguish core, supporting and generic subdomains.
3. Use strategic DDD tools, including context maps, to identify service boundaries.
4. Evaluate decomposition patterns, service granularity and data ownership.
5. Analyse coupling, cohesion, autonomy and transaction boundaries.
6. Design an evolutionary architecture that can change safely over time.
7. Identify operational, governance, security and organizational consequences of microservice adoption.

1. The Domain as the Starting Point

A domain is the area of knowledge, activity or business concern for which a system is built. In an online retail organization, the domain may include product discovery, ordering, payment, fulfilment, customer support and marketing. In a university, the domain may include admissions, registration, assessment, timetabling and research administration.

The domain is broader than the software system. It includes people, policies, regulations, physical processes and organizational objectives. A software architecture is therefore an interpretation of the domain, not a complete representation of it.

1.1 Domain language

Domain experts and developers often use different terms for the same concept. DDD addresses this problem through a ubiquitous language: a shared vocabulary used in conversations, requirements, code, tests, documentation and interfaces. The language should be precise within a particular context.

For example, the word “customer” may mean a person who has registered an account in one part of a business, the legal payer in another, and the recipient of a shipment in a third. Treating all uses as one universal entity can create incorrect assumptions. The more useful question is not “What is the one true Customer object?” but “What does customer mean in this business context?”

Ubiquitous language is developed collaboratively through domain workshops, event storming, process modelling, examples and review of existing terminology. It is not merely a glossary created after implementation.

1.2 Business capabilities and processes

A business capability describes what an organization is able to do, such as “price an order,” “issue a refund” or “allocate inventory.” A business process describes how activities are sequenced to achieve an outcome, such as the steps from shopping-cart submission to shipment.

Capabilities are often more stable than processes. A process may change because of a new channel or policy, while the underlying capability remains. Capability-based decomposition is therefore often useful for identifying candidate services, although a capability is not automatically a service. A capability may be implemented by several services, or several closely related capabilities may belong in one service.

2. Subdomains and Strategic Classification

DDD divides a domain into subdomains. A subdomain is a distinct area of business knowledge or responsibility within the larger domain. Subdomains help architects decide where to invest design effort and where to use existing software.

2.1 Core subdomain

The core subdomain contains the organization’s main competitive differentiator. It is the area in which specialized business rules create strategic value. Examples include a financial institution’s risk-pricing algorithm or a logistics company’s route-optimization capability.

The core subdomain normally deserves:

• close collaboration between domain experts and engineers;
• deliberate modelling and explicit business language;
• strong automated testing;
• architectural flexibility;
• ownership by a stable, skilled team.

The core is not necessarily the largest part of the system. A small but strategically decisive capability may be more important than a large administrative function.

2.2 Supporting subdomain

A supporting subdomain is necessary for the business but does not usually provide major competitive differentiation. Examples include supplier onboarding, internal approval workflows or operational reporting. Such areas require an appropriate level of engineering quality, but they should not consume the same investment as the core.

Supporting subdomains may be implemented as custom services, modular components or carefully selected third-party products, depending on risk, cost and organizational capability.

2.3 Generic subdomain

A generic subdomain represents a common capability that many organizations need and that is not strategically distinctive. Authentication, tax calculation, email delivery and document storage may fall into this category, although classification depends on the organization.

Generic capabilities are candidates for commercial software, open-source components or shared platforms. Reusing a generic solution can reduce cost, but it introduces dependency, vendor and integration risks. “Generic” does not mean “unimportant”; failure in identity or payment infrastructure can be severe even when the capability is not a competitive differentiator.

3. Bounded Contexts

A bounded context is an explicit boundary within which a particular domain model and its language are valid. The boundary may be represented by a service, a module, a team responsibility or another architectural unit. A bounded context prevents concepts from one model being assumed to have the same meaning in another.

For example, an organization might have the following bounded contexts:

• Sales: a product is something offered to a buyer at a price.
• Inventory: a product is a stock-keeping unit with quantity and location.
• Shipping: a product is a physical item with dimensions, weight and handling requirements.
• Accounting: a product sale is a financial transaction with tax and ledger implications.

These contexts may exchange information, but they do not need to share one large Product class or one database schema. Each context owns the concepts needed for its responsibilities.

3.1 Bounded context versus microservice

A bounded context and a microservice are related but not identical. A bounded context is primarily a modelling and linguistic boundary. A microservice is a deployable and operational boundary. A bounded context may initially be implemented as a module in a monolith and extracted later. Conversely, one microservice may contain more than one bounded context, although this can create confusion if the contexts have substantially different ownership or change rates.

A strong candidate for a microservice usually has:

• a coherent business responsibility;
• a clear owner;
• a stable public contract;
• data that it can own;
• a manageable operational profile;
• a reason to change or scale independently.

Deployment independence alone is insufficient. If a service cannot be changed, tested or operated without coordinating several other services, its practical autonomy is weak.

3.2 Entities, value objects and aggregates

DDD tactical patterns help model behaviour inside a bounded context.

An entity has an identity that remains meaningful across changes. An order may retain the same order identifier even when its status, address or line items change.

A value object is defined by its attributes rather than by identity. Money, postal addresses and date ranges are common examples. Value objects are often immutable, which reduces accidental side effects.

An aggregate is a consistency boundary containing related objects. One entity acts as the aggregate root, and external code should normally modify the aggregate through that root. The aggregate boundary should be small enough to support practical transactions and strong enough to protect important invariants.

An invariant is a rule that must hold whenever the aggregate is in a valid state. For example, an order may require that its total equal the sum of its approved line items and that a cancelled order cannot be shipped. Not every relationship in the domain belongs inside one aggregate. Placing too many objects in one aggregate creates contention and makes independent change difficult.

4. Context Maps and Relationships Between Contexts

A context map describes relationships between bounded contexts. It makes dependencies, translation responsibilities and power relationships visible. Typical relationships include the following.

• Partnership: two teams coordinate changes and share responsibility for an integration.
• Customer–supplier: one context supplies an interface and another consumes it; the supplier should consider the customer’s needs.
• Conformist: the downstream context adopts the upstream model without translation, often because it has little influence.
• Anticorruption layer: a translation layer protects one context from an unsuitable or unstable external model.
• Open host service: a context publishes a well-defined protocol intended for multiple consumers.
• Published language: contexts communicate using a shared, documented format.
• Separate ways: contexts avoid integration where the cost of coordination is greater than the value.

An anticorruption layer is particularly important when integrating with legacy systems. It may translate names, units, statuses and business rules. It prevents legacy concepts from leaking into the new domain model, although the layer itself has a maintenance cost.

Figure: A simplified context map. Each context owns its model and communicates through explicit contracts or translated events.

A context map is not merely a diagram. It supports decisions about contract ownership, integration testing, change coordination and organizational responsibility.

5. Decomposition Patterns

There is no universally correct decomposition method. Architects should compare several views of the domain and look for consistent boundaries.

5.1 Decomposition by business capability

Each service represents a business capability such as catalogue management, ordering or delivery. This often aligns service ownership with business outcomes and limits the impact of organizational change.

5.2 Decomposition by subdomain or bounded context

A service is organized around a domain model and its language. This approach is closely associated with DDD and is effective when business rules are complex. It requires careful discovery because apparently similar functions may belong to different contexts.

5.3 Decomposition by workflow step

Services represent stages in a process, such as validation, payment and dispatch. This can make process ownership visible, but it may create excessive coordination if each stage requires synchronous calls or shared transactions.

5.4 Decomposition by data ownership

A service owns a dataset and the operations that protect its invariants. Other services access the data through an API or events rather than directly querying its database. This supports autonomy but can require deliberate handling of duplicated read models and eventual consistency.

5.5 Decomposition by volatility or scaling profile

Components that change frequently or require independent scaling may be separated. This is a useful technical consideration, but volatility alone should not override domain cohesion. Separating code only because it currently receives high traffic can create a boundary that is difficult to understand and govern.

6. Service Granularity and the Distributed Monolith

Service granularity refers to the size and scope of a service. “Small” should not be defined by lines of code or the number of classes. A service is appropriately sized when its responsibility is coherent, its dependencies are manageable and its team can understand and operate it.

6.1 Signs of excessive granularity

Excessively fine-grained services often exhibit:

• chains of synchronous calls for ordinary operations;
• frequent coordinated releases;
• shared database tables or cross-service joins;
• repeated deployment failures caused by dependency order;
• difficult local development;
• duplicated validation and business rules;
• high monitoring and networking overhead relative to business value.

6.2 Signs of insufficient granularity

A service may be too broad when it contains unrelated business languages, has several independent owners, changes for many unrelated reasons, or requires separate scaling and security policies. A modular monolith may be preferable until these differences become significant.

6.3 Practical evaluation dimensions

Service boundaries should be evaluated using several dimensions rather than a single rule.

A useful qualitative principle is to place together elements that change together and separate elements that change independently. This is not a mathematical law; it is a design heuristic that must be tested against domain evidence.

7. Data Ownership, Consistency and Communication

A microservice should normally own the data required to enforce its business rules. Direct access by other services creates hidden coupling and permits external code to bypass invariants. Data ownership does not necessarily require a separate database server for every service, but it does require a clear ownership boundary and controlled access.

7.1 Synchronous and asynchronous communication

Synchronous communication, such as a request–response API, is appropriate when the caller needs an immediate answer and the dependency is acceptable. It is simple to understand but couples availability and latency: if the dependency is unavailable, the caller may fail or wait.

Asynchronous communication, often through events or queues, allows temporal decoupling. A producer publishes that something has happened, and consumers process the message independently. This improves resilience and scalability but introduces eventual consistency, duplicate delivery, ordering concerns and more difficult tracing.

An event should describe a completed fact, such as “OrderPlaced” or “PaymentAuthorized,” rather than expose another service’s internal command structure. Event schemas require versioning, ownership and compatibility practices.

7.2 Distributed transactions and sagas

A transaction spanning several services is difficult because failures can occur between local commits. Two-phase commit can provide coordination in some environments, but it increases coupling and operational complexity and is not a universal solution.

A saga coordinates a business operation through a sequence of local transactions. If a later step fails, compensating actions attempt to undo or counteract earlier steps. Compensation is not always a perfect reversal. A refund, for example, may compensate for a charge, but it may not erase all external consequences.

Sagas can be orchestrated by a coordinator or choreographed through events. Orchestration makes control flow explicit; choreography reduces central control but can become difficult to understand when many services react to one another.

8. Ownership, Teams and Conway’s Law

Architecture is influenced by organizational communication structures. Conway’s Law proposes that systems tend to reflect the communication patterns of the organizations that design them. If several teams must coordinate continuously to change one service, the architecture may reproduce that coordination burden.

A service should have clear ownership for its code, data, interfaces, security posture, operational alerts and lifecycle. Ownership is not merely permission to commit code. It includes accountability for reliability, documentation, compatibility and incident response.

Team Topologies provides a complementary perspective: teams should have manageable cognitive load and clear interaction modes. A platform team may provide deployment, observability and security capabilities, while stream-aligned teams own business outcomes. Platform services must not become a dumping ground for unclear business responsibilities.

9. Evolutionary Architecture

An evolutionary architecture is designed to change safely as understanding improves. In domain modelling, boundaries are hypotheses. Real usage, incidents, regulatory changes and business experiments provide evidence that may confirm or challenge them.

9.1 Fitness functions

An architectural fitness function is a repeatable test that checks whether an architectural property remains within an acceptable range. Examples include:

• a service must not access another service’s database;
• public API changes must remain backward compatible for a defined period;
• critical requests must meet a latency objective;
• personally identifiable information must not appear in application logs;
• dependency graphs must not contain prohibited cycles.

Fitness functions turn architectural intent into observable controls. They should be automated where practical and reviewed when business priorities change.

9.2 Refactoring and strangler migration

A monolith need not be replaced in one operation. In a strangler approach, a new capability is built around or beside an existing system. Traffic is gradually redirected while the old implementation is retired in slices.

A safe migration commonly requires:

1. identifying a bounded capability with a clear interface;
2. establishing tests around current behaviour;
3. introducing an anti-corruption or translation layer;
4. moving ownership of selected data and rules;
5. routing a controlled proportion of traffic;
6. observing correctness and operational effects;
7. removing obsolete paths.

The migration should avoid creating a permanent dual-write arrangement without a clear consistency strategy. During transition, reconciliation jobs, audit records and explicit ownership dates may be necessary.

10. A Structured Boundary-Design Method

The following method can be used in an architecture workshop.

Step 1: Identify business outcomes

List the outcomes the organization must achieve, not merely the screens or technical components it currently uses.

Step 2: Discover domain language

Collect important nouns, verbs, policies, events and exceptions. Ask domain experts to define ambiguous terms and provide concrete examples.

Step 3: Map capabilities and subdomains

Classify capabilities as core, supporting or generic. Record strategic importance, complexity, regulatory exposure and current pain points.

Step 4: Find bounded contexts

Look for changes in language, ownership, rules, lifecycle and data meaning. A boundary is stronger when several of these signals coincide.

Step 5: Map relationships

Identify upstream and downstream dependencies, translation points, contracts, events and likely failure modes.

Step 6: Test candidate services

Evaluate cohesion, coupling, data ownership, team responsibility, operational independence and expected change.

Step 7: Choose the least risky implementation

The result may be a microservice, a modular monolith, a shared platform capability or a staged migration. Architecture should follow evidence rather than fashion.

Step 8: Establish feedback mechanisms

Use domain review, contract tests, production telemetry, incident analysis and change metrics to test whether the boundary remains useful.

11. Illustrative Case: A University Enrolment Platform

Background

A university operates a legacy enrolment platform covering applications, course registration, fee assessment, timetable allocation and examination records. All functions share one database. Small changes require large regression tests, and several teams modify the same tables.

Problem

The university wants to introduce online self-service registration and support a new short-course division. The existing system cannot scale registration traffic independently, and the meaning of “student status” differs between admissions, registration and finance.

Analysis

A workshop identifies several capabilities: admissions evaluation, student identity, course registration, fee assessment, timetable allocation and examination management. Admissions and registration both use the word “student,” but admissions treats an applicant as a candidate, whereas registration requires an accepted and eligible learner. Finance uses a student account for billing and does not need all academic details.

Admissions evaluation is a supporting capability, while registration and progression rules are strategically important because they are central to the university’s differentiated academic model. Identity and payment processing are partly generic, subject to regulatory and institutional requirements.

Approach

The architects define bounded contexts rather than immediately creating one service per database table:

• Admissions context: application, decision and offer models.
• Registration context: eligibility, module selection and enrolment models.
• Finance context: charges, payments and refunds.
• Academic records context: marks, credits and progression history.
• Identity context: authentication and institutional identity.

The registration context owns the rule that a learner may register only when prerequisites, capacity and registration windows permit. Finance receives an event such as “RegistrationAccepted” and creates charges using its own model. Academic records receives confirmed enrolment information but does not directly query registration tables.

An anticorruption layer translates legacy statuses into the new registration vocabulary. Initially, the registration context is implemented as a well-isolated module in the existing deployment. Contract tests and event logging are introduced before it is extracted as a separately deployable service.

Outcome

The university can scale registration independently during peak periods and change registration rules without modifying finance tables. Some information is eventually consistent: a successful registration may appear in the finance portal shortly after it is accepted. The user interface therefore displays a clear processing state rather than incorrectly promising immediate financial completion.

Learning points

1. Similar nouns do not guarantee a shared model.
2. Data ownership should follow business rules and accountability.
3. A modular monolith can be a valid evolutionary step.
4. Events create decoupling but require explicit handling of delay and failure.
5. Service boundaries should be tested through real change and operational evidence.

12. Governance, Security and Ethical Considerations

Microservice decomposition creates governance responsibilities that are easy to underestimate.

Privacy: Personal data should be classified, minimized and accessed only for legitimate purposes. Data duplication across services increases the number of locations that must be protected and erased when required by law.

Access control: Authorization belongs near the business decision it protects. A gateway can authenticate a request, but the owning context must determine whether the requested action is permitted. Service-to-service identity, least privilege and secret rotation are essential.

Auditability: Important actions such as refunds, grade changes or eligibility decisions should produce tamper-resistant audit records with actor, time, reason and correlation information.

Regulatory compliance: Sector rules may require retention, explainability, data residency, financial controls or breach notification. Decomposition does not remove these obligations; it distributes them across more components.

Algorithmic fairness: If a service uses automated eligibility, pricing or prioritization, designers should examine data quality, discriminatory effects, human review and the ability to explain decisions. AI components should not be treated as neutral simply because they are deployed as services.

Operational responsibility: Independent deployment can increase failure frequency if teams lack testing, observability and incident processes. Governance should enable safe autonomy rather than impose approval queues for every change.

13. Contemporary Developments and Limitations

Serverless platforms increasingly host individual microservice functions, event handlers and workflow steps. This can reduce infrastructure management but may intensify concerns about cold starts, vendor-specific interfaces, distributed tracing, execution limits and fragmented ownership. Serverless does not remove the need for sound domain boundaries.

Service meshes provide traffic management, security policy and telemetry, but they do not fix an incoherent domain model. Similarly, containers simplify packaging and deployment but do not create autonomy or good ownership.

AI-assisted coding can accelerate implementation, test generation and documentation. However, generated code may reproduce incorrect domain assumptions, expose data or create inconsistent contracts. Domain experts and accountable engineers must review generated artefacts, especially in regulated contexts.

Microservices also have structural limitations. They increase network communication, operational tooling, deployment complexity and the number of failure modes. Distributed systems make debugging and testing harder. For a small team or a stable application, a modular monolith may provide better reliability and lower total cost. The appropriate architecture depends on domain complexity, team structure, scale, risk and expected change.

Best-Practice Checklist

• Begin with business capabilities and domain language, not deployment technology.
• Define bounded contexts where meanings, rules, ownership or change patterns differ.
• Keep the core domain under strong domain-expert and engineering stewardship.
• Give each service clear data ownership and avoid shared database writes.
• Prefer explicit contracts and domain events over hidden coupling.
• Keep aggregates small and align them with meaningful consistency boundaries.
• Treat synchronous calls as availability dependencies and design for failure.
• Use modular monoliths and incremental extraction when they reduce risk.
• Automate contract, security, privacy and architectural fitness checks.
• Make ownership include operations, compatibility, security and retirement.
• Measure outcomes such as lead time, failure recovery and business change—not service count.
• Revisit boundaries using production evidence and organizational learning.

Chapter Summary

Microservice architecture is most effective when service boundaries reflect meaningful business responsibilities rather than arbitrary technical subdivisions. Domain-Driven Design supplies the concepts needed for this work: domains contain subdomains; subdomains may be core, supporting or generic; bounded contexts establish the limits of valid language and models; and context maps describe relationships between those contexts.

A microservice is a deployment and ownership boundary, whereas a bounded context is primarily a modelling boundary. They often align, but they should not be confused. Effective services exhibit cohesive responsibilities, explicit contracts, controlled data ownership and sufficient operational autonomy. Excessive granularity produces distributed monoliths, while excessive breadth hides independent models and change patterns.

Communication choices have architectural consequences. Synchronous calls create direct availability dependencies, while asynchronous events provide temporal decoupling at the cost of eventual consistency and more complex failure handling. Sagas can coordinate distributed business processes, but compensation is not always a perfect reversal.

Evolutionary architecture recognizes that boundaries are hypotheses. Fitness functions, modular monoliths, strangler migrations, contract tests and production feedback allow systems to evolve without requiring a risky rewrite. Finally, privacy, security, auditability, regulatory compliance, organizational ownership and operational capability are integral to architecture. The goal is not to maximize the number of services, but to create a system that can change safely while preserving business meaning and user value.

Key Terms

Domain: The area of business activity, knowledge and rules addressed by a system.

Subdomain: A distinct area of responsibility within a larger domain.

Core subdomain: The strategically differentiating part of a domain.

Supporting subdomain: A necessary but usually non-differentiating business capability.

Generic subdomain: A common capability often suitable for reuse or purchase.

Ubiquitous language: Shared, precise terminology used by domain experts and developers.

Bounded context: A boundary within which a domain model and its language are valid.

Context map: A description of relationships and dependencies between bounded contexts.

Entity: A domain object defined by persistent identity.

Value object: An object defined by its attributes rather than identity.

Aggregate: A consistency boundary containing related domain objects.

Aggregate root: The entity through which an aggregate is controlled externally.

Invariant: A rule that must hold for a valid domain state.

Anticorruption layer: A translation mechanism that protects one model from another.

Data ownership: Accountability for the data and rules maintained by a service or context.

Domain event: A record of a significant business fact that has occurred.

Saga: A sequence of local transactions coordinated across services.

Fitness function: A repeatable test of an architectural property.

Evolutionary architecture: Architecture designed to change safely through incremental evidence and controlled adaptation.

Distributed monolith: A multi-service system whose strong coupling prevents meaningful independent change.

Review Questions

Short Answer Questions

1. What is the difference between a domain and a subdomain?
2. Why can the same business term have different meanings in different bounded contexts?
3. State two characteristics of an appropriately sized microservice.
4. What problem does an anticorruption layer address?
5. Why is a shared database often a source of coupling between services?

Long Answer Questions

1. Explain how core, supporting and generic subdomains influence architectural investment and implementation choices.
2. Compare bounded contexts and microservices. Why should an architect avoid treating them as identical concepts?
3. Discuss the advantages and disadvantages of synchronous and asynchronous communication in a microservice system.
4. Explain how aggregates, invariants and data ownership contribute to service autonomy.
5. Describe how an organization could migrate from a monolith using evolutionary architecture and a strangler approach.

Analytical / Application Questions

1. A food-delivery company has separate teams for restaurant onboarding, menu management, order placement, courier dispatch and customer refunds. Propose candidate bounded contexts and explain at least two likely context-map relationships.
2. A proposed design contains twelve services, all reading a common customer database and requiring coordinated deployment. Analyse the design using cohesion, coupling, ownership and evolutionary-architecture criteria. Recommend a safer alternative.
3. During examination registration, a student is accepted by the registration service but the finance service is temporarily unavailable. Design an interaction using events or a saga, explain the resulting consistency model and identify appropriate user-facing and audit behaviour.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a bounded context?

A. A database server dedicated to one microservice

B. A boundary within which a domain model and language have a defined meaning

C. A network segment containing all application services

D. A deployment pipeline used by one engineering team

Correct Answer: B. A boundary within which a domain model and language have a defined meaning

Question 2

Which type of subdomain normally deserves the greatest investment in specialized modelling?

A. Generic subdomain

B. Supporting subdomain

C. Core subdomain

D. Infrastructure subdomain

Correct Answer: C. Core subdomain

Question 3

What is the primary purpose of an anticorruption layer?

A. To increase database query speed

B. To translate and protect a local model from an external model

C. To combine all services into one deployment

D. To eliminate the need for domain experts

Correct Answer: B. To translate and protect a local model from an external model

Question 4

Which is a common sign of a distributed monolith?

A. Services have independent data ownership

B. Services use explicit versioned contracts

C. Services require frequent coordinated releases

D. Services publish domain events

Correct Answer: C. Services require frequent coordinated releases

Question 5

What does a value object primarily use to define equality?

A. Its network address

B. Its deployment version

C. Its attributes or values

D. The identity of its aggregate root

Correct Answer: C. Its attributes or values

Question 6

Which communication style generally introduces eventual consistency when used between services?

A. Asynchronous event communication

B. A local function call

C. An in-process method invocation

D. A database transaction within one service

Correct Answer: A. Asynchronous event communication

Question 7

What is the main responsibility of an aggregate root?

A. To expose every internal object directly to other services

B. To control access to changes within its aggregate

C. To own the databases of all related contexts

D. To coordinate every enterprise workflow

Correct Answer: B. To control access to changes within its aggregate

Question 8

Which practice best supports evolutionary architecture?

A. Prohibiting all changes to service boundaries

B. Measuring only the number of deployed services

C. Using automated fitness functions to check architectural properties

D. Sharing database writes to simplify migration

Correct Answer: C. Using automated fitness functions to check architectural properties

Question 9

In the university enrolment case, why should finance avoid directly querying registration tables?

A. Direct queries always reduce performance

B. Finance and registration use different models and should preserve data ownership

C. Finance cannot process events

D. Registration data can never be shared

Correct Answer: B. Finance and registration use different models and should preserve data ownership

Question 10

Which statement about microservices and bounded contexts is most accurate?

A. Every bounded context must immediately be a separate microservice

B. A microservice is primarily a linguistic concept, while a bounded context is only a deployment unit

C. They are related concepts, but a bounded context may initially be implemented as a module

D. Neither concept concerns ownership or business language

Correct Answer: C. They are related concepts, but a bounded context may initially be implemented as a module