Requirements and Domain Modeling

Introduction

Software systems succeed when they solve the right problem for the right stakeholders, not merely when they are implemented efficiently. Requirements engineering is the disciplined process of discovering, analyzing, documenting, validating, prioritizing, and managing what a system must accomplish and the constraints under which it must operate. Domain modeling complements this work by representing the important concepts, relationships, rules, and boundaries of the problem domain.

In advanced software development, requirements are not treated as a static list handed to programmers. They are evolving claims about user needs, organizational goals, legal obligations, operational constraints, and system behavior. Domain models provide a shared vocabulary that connects these claims to software structure. Together, requirements and domain models reduce ambiguity, expose conflicts, support estimation, and guide architecture, implementation, testing, and maintenance.

This chapter presents practical and analytical techniques for eliciting and validating functional and non-functional requirements, writing use cases and user stories, defining acceptance criteria, constructing domain models, applying domain-driven design, establishing traceability, and prioritizing work.

Learning Objectives

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

• distinguish functional requirements from non-functional requirements and constraints;
• identify stakeholders and apply suitable elicitation techniques;
• write effective use cases, user stories, and acceptance criteria;
• validate requirements for quality, feasibility, consistency, and testability;
• construct conceptual domain models using entities, value objects, aggregates, and relationships;
• explain bounded contexts and the strategic ideas of domain-driven design;
• establish requirements traceability across goals, requirements, design, code, and tests;
• prioritize requirements using value, urgency, risk, cost, and dependency;
• analyze a realistic requirements and modeling problem critically.

1. The Nature of Requirements

A requirement is a needed capability, condition, or constraint. Requirements may express what users want, what a business must achieve, what a system must do, or what qualities and restrictions apply to the solution. A useful requirements statement has a clear subject, an observable behavior or condition, and sufficient context for evaluation.

1.1 Stakeholders and viewpoints

A stakeholder is any person, group, or organization that affects, is affected by, or has an interest in the system. Stakeholders may include customers, end users, administrators, managers, regulators, support staff, suppliers, security officers, and developers. Their interests often differ. A customer may seek convenience, a regulator may require auditability, and an operations team may require recoverability.

Requirements are therefore viewpoint-dependent. The same system may be described as:

• a service that enables a customer to place an order;
• a source of revenue for a business;
• a controlled process for an auditor;
• a workload requiring monitoring for an operations team.

A requirements engineer must identify these viewpoints rather than assuming that one stakeholder represents the whole system.

1.2 Functional requirements

Functional requirements describe services, behaviors, transformations, or responses that the system shall provide. Examples include:

• The system shall allow a registered customer to reset a forgotten password.
• The system shall calculate tax using the applicable jurisdictional rules.
• The system shall notify a customer when an order is dispatched.

A functional requirement should identify observable behavior. “The system shall be user-friendly” is not functional and is too vague to test; “The system shall allow a trained user to complete a standard booking in no more than five screens” is more measurable, although it also expresses a usability quality.

1.3 Non-functional requirements and constraints

Non-functional requirements describe qualities, performance levels, security properties, operational conditions, or restrictions. They often apply across many functional requirements. Examples include:

• Performance: 95% of search requests shall receive a response within two seconds under a specified workload.
• Availability: The service shall achieve 99.9% monthly availability, excluding agreed maintenance windows.
• Security: Administrative access shall require multi-factor authentication.
• Accessibility: User interfaces shall conform to the organization’s adopted accessibility standard.
• Maintainability: Business rules shall be isolated from presentation-specific code.
• Legal constraint: Personal data shall be retained only for the period permitted by policy and law.

A non-functional requirement must be measurable or verifiable where possible. “The system shall be secure” is an aspiration. “After five failed login attempts within 15 minutes, the account shall be locked for 15 minutes and the event shall be logged” is testable.

Quality attributes can conflict. Stronger authentication may increase friction; extensive logging may increase storage and privacy risk; high availability may increase cost. Requirements analysis must make such trade-offs explicit.

1.4 Requirements levels

Requirements can be organized into levels:

A good requirements hierarchy preserves the connection between business purpose and technical detail.

2. Requirements Elicitation

Elicitation is the systematic discovery of requirements. No single technique is sufficient because stakeholders may not know what they need, may use inconsistent terminology, or may omit routine assumptions.

2.1 Common elicitation techniques

Interviews provide depth and allow follow-up questions. Structured interviews improve comparability; semi-structured interviews allow discovery. The interviewer should ask about goals, exceptions, decisions, information used, and consequences of failure rather than merely asking, “What features do you want?”

Workshops bring multiple stakeholders together to negotiate a shared understanding. They are effective for process mapping, prioritization, and resolving terminology conflicts, but dominant participants can silence less powerful viewpoints.

Observation and contextual inquiry reveal actual work practices. They are especially valuable where documented procedures differ from real behavior. The analyst should distinguish necessary work from accidental workarounds caused by existing systems.

Document analysis examines policies, forms, contracts, regulations, manuals, support records, and existing interfaces. Documents reveal constraints and institutional language, but they may be outdated.

Prototyping uses sketches, wireframes, simulations, or executable prototypes to expose misunderstandings. A prototype is a learning instrument, not automatically a commitment to implement every displayed feature.

Surveys collect input from large populations efficiently. They are useful for confirming patterns but usually provide less depth than interviews or observation.

Event analysis starts with business events such as “payment received,” “shipment delayed,” or “membership expires,” then identifies required responses, responsible actors, data, and rules.

2.2 Elicitation quality

Effective elicitation is inclusive, iterative, and evidence-based. Analysts should record assumptions, unresolved questions, alternative interpretations, and stakeholder ownership. Sensitive domains require attention to people who may be underrepresented, including users with disabilities, minority language users, and individuals affected by automated decisions.

A requirements workshop should normally establish its scope, vocabulary, participants, decision rules, outputs, and follow-up responsibilities. Decisions should be recorded with rationale, not merely as unexplained conclusions.

3. Use Cases, User Stories, and Acceptance Criteria

Different representations serve different purposes. Use cases describe interactions and goals in a structured way. User stories provide concise, user-centered statements useful for iterative planning. Acceptance criteria define conditions under which a requirement is considered satisfied.

3.1 Use cases

A use case describes a goal-oriented interaction between an actor and a system. Its essential elements commonly include:

• name and goal;
• primary actor;
• supporting actors or external systems;
• preconditions;
• trigger;
• main success scenario;
• alternative and exception flows;
• postconditions;
• business rules and special requirements.

Illustrative use case: Submit an equipment loan request

• Primary actor: Student
• Preconditions: The student is authenticated and the equipment catalogue is available.
• Trigger: The student selects “Request equipment.”
• Main success scenario:

1. The system displays eligible equipment.
2. The student selects an item and loan dates.
3. The system checks availability and eligibility.
4. The student confirms the request.
5. The system records the request and sends confirmation.

• Alternative flow: If the item is unavailable, the system offers a wait-list option.
• Exception flow: If the student has overdue equipment, the system rejects the request and explains the reason.
• Postcondition: A confirmed request exists or a rejection is recorded.

Use cases should describe externally observable behavior rather than internal classes or database tables. They are particularly useful when many steps, exceptions, or actors must be analyzed.

3.2 User stories

A user story is a concise statement of a user-valued outcome, commonly expressed as:

As a [role], I want [capability], so that [benefit].

For example: “As a student, I want to see equipment availability before requesting an item, so that I do not submit an unsuccessful request.”

A useful story is often evaluated using the INVEST heuristic: Independent, Negotiable, Valuable, Estimable, Small, and Testable. Independence is desirable but not always fully achievable; dependencies should be made visible rather than hidden.

User stories are not complete specifications. Conversation among stakeholders and developers supplies detail, while acceptance criteria define the boundary of completion.

3.3 Acceptance criteria

Acceptance criteria are specific conditions that must be met for a requirement to be accepted. They should cover the normal case, important alternatives, validation rules, permissions, and relevant quality conditions.

For the equipment story, criteria might include:

• Given an authenticated student, when an equipment item is selected, then the system displays its availability for the requested dates.
• Given no availability, when the student views the item, then the system does not permit a confirmed request for those dates.
• Given an overdue item, when the student submits a request, then the system rejects it and displays the overdue-item message.

The Given–When–Then form separates context, event, and expected outcome. Criteria should be observable and independently testable. “The interface is intuitive” is weak unless accompanied by an agreed usability test and measurable target.

4. Validating Requirements

Validation asks whether requirements describe the right system and whether they are expressed well enough to guide development and testing. Important validation properties include:

• Correctness: The requirement reflects an actual stakeholder or organizational need.
• Completeness: Necessary normal, alternative, exception, data, and quality behavior is covered.
• Consistency: Requirements do not contradict one another.
• Unambiguity: Different readers are unlikely to interpret the statement differently.
• Feasibility: The requirement can be achieved within technological, legal, schedule, and budget constraints.
• Verifiability: A test, inspection, demonstration, or analysis can determine whether it is satisfied.
• Traceability: Its origin and downstream implementation or verification artifacts can be identified.
• Prioritization: Its relative importance is known.

A review checklist is useful, but validation should also use prototypes, executable acceptance tests, domain expert review, model walkthroughs, and consistency analysis. Stakeholders should review requirements in terms they understand; technical notation must not become a barrier to participation.

Ambiguous words require attention. Terms such as “fast,” “simple,” “secure,” “regularly,” and “appropriate” should be replaced with measurable definitions or explicitly negotiated interpretations.

Requirements are also subject to change. Change control should record the proposed change, reason, affected stakeholders, impact on scope and architecture, priority, decision, and links to affected tests and documentation. Change control does not mean refusing change; it means making consequences visible.

5. Domain Modeling

A domain model is a conceptual representation of the important concepts and relationships in a problem domain. It is not necessarily a database schema, class diagram, or final implementation design. Its purpose is to create a shared model of the domain and to reveal missing concepts and rules.

5.1 Concepts and relationships

A model may contain:

• Entities: Objects with a distinct identity that persists through changes, such as Student, Loan, or Account.
• Value objects: Descriptive objects defined by their attributes rather than identity, such as Money, Address, DateRange, or EmailAddress. They are often immutable.
• Attributes: Relevant properties of concepts.
• Associations: Meaningful relationships, with multiplicity and role names where helpful.
• Domain events: Significant occurrences, such as LoanApproved or PaymentReceived.
• Business rules: Conditions that determine valid states or behavior.

Consider the statement: “A student may have many loans, but each loan concerns one equipment item and has a start and due date.” A conceptual model could represent Student, Loan, and Equipment, with Student-to-Loan multiplicity of zero-to-many and Loan-to-Equipment multiplicity of exactly one. The model should also state rules such as “a student cannot receive a new loan while suspended.”

5.2 Discovering concepts

Nouns in domain conversations can suggest candidate concepts, while verbs suggest behavior and relationships. However, grammatical nouns are not automatically domain objects. “Request” may be a meaningful domain entity, whereas “screen” may belong only to the interface. Analysts should ask:

• Does the concept have identity or lifecycle?
• Does it participate in important business rules?
• Is it merely a description that should be a value object?
• Is the proposed concept an implementation artifact rather than a domain concept?

A model should be tested through scenarios. If a scenario cannot be explained naturally using the model’s vocabulary, the model may be incomplete or poorly formed.

5.3 Domain-driven design

Domain-driven design (DDD) treats the domain model as a central design tool and emphasizes collaboration between domain experts and developers. It distinguishes strategic modeling from tactical patterns.

Strategic DDD begins with the core domain, where the organization seeks distinctive advantage, and separates it from supporting and generic subdomains. It also identifies bounded contexts: explicit boundaries within which a model and its terminology have consistent meaning.

For example, “customer” may mean a person who buys a product in Sales, an account holder in Billing, and a delivery recipient in Logistics. A single universal Customer class can create confusion and excessive coupling. Separate bounded contexts can maintain models suited to their purposes, with explicit integration relationships.

A context map documents relationships between bounded contexts, such as:

• partnership, where teams coordinate changes;
• customer–supplier, where one context supplies services to another;
• conformist, where a downstream context adopts an upstream model;
• anti-corruption layer, where translation protects one model from another;
• published language, where an agreed integration representation is shared.

Tactical DDD includes entities, value objects, aggregates, repositories, domain services, domain events, and factories. An aggregate is a consistency boundary containing a root entity. External references normally point to the aggregate root, and invariants inside the boundary are enforced through it. Aggregates should not be made arbitrarily large; a large aggregate increases contention and makes transactions costly.

A repository provides access to domain objects or aggregates without exposing persistence details to the domain model. A domain service represents domain logic that does not naturally belong to one entity or value object. These patterns are useful only when they clarify the domain; applying them mechanically can produce unnecessary abstraction.

6. Traceability and Prioritization

6.1 Requirements traceability

Traceability links a requirement to its source, related goals, design elements, implementation work, tests, and release decisions. A traceability matrix may contain relationships such as:

Traceability supports impact analysis, regulatory evidence, test coverage assessment, and change management. It should not become a bureaucratic document maintained without purpose. Automated links from issue trackers, source repositories, and test systems can reduce duplication.

Forward traceability follows a business need toward implementation and tests. Backward traceability verifies that each implemented feature is justified by an approved requirement. Both are valuable: forward links reveal missing tests, while backward links reveal scope expansion or unauthorized functionality.

6.2 Prioritization

Prioritization is a decision about relative importance under constraints. A requirement’s priority may depend on business value, user impact, risk reduction, compliance, urgency, cost, technical dependency, and learning value.

The MoSCoW method classifies requirements as Must have, Should have, Could have, or Won’t have for the current release. It is easy to communicate, but teams must limit the number of “Must” items or the classification loses meaning.

A weighted scoring model can make criteria explicit. Suppose a team scores value, risk reduction, and urgency from 1 to 5, with weights 0.5, 0.3, and 0.2. The weighted score is:

Here, S is the priority score, and V, R, and U are the criterion scores. The weights sum to 1, and the method is meaningful only when the scoring scale and criteria are agreed. The score is a decision aid, not an objective truth. Cost, dependencies, and legal obligations may override it.

For example, a requirement scored V = 5, R = 4, U = 3 has:

A lower-scoring compliance requirement may still be mandatory. Prioritization should therefore include explicit non-negotiable constraints and document the rationale for trade-offs.

7. Integrated Illustrative Case: University Equipment Lending

Background

A university currently manages cameras, laptops, and laboratory equipment through spreadsheets and email. Students cannot reliably see availability, staff manually check overlapping requests, and overdue items are difficult to track.

Problem analysis

Stakeholders include students, lending staff, faculty supervisors, finance staff, IT operations, and the university’s privacy office. Initial interviews reveal conflicting meanings of “available”: staff use it to mean physically present and serviceable, while students use it to mean reservable for their chosen dates.

The analyst identifies these candidate concepts: Student, EquipmentItem, Reservation, Loan, MaintenanceRecord, Fine, and EligibilityStatus. “Availability” is modeled as a derived business concept rather than a stored Boolean because it depends on dates, reservations, maintenance, and current loans.

Key functional requirements are:

• Students shall search equipment by category and date range.
• The system shall prevent overlapping confirmed reservations for the same item.
• Staff shall issue and return equipment.
• The system shall calculate overdue status from the due date and return time.
• The system shall notify students of approval, rejection, and overdue status.

Non-functional requirements include authenticated access, role-based authorization, audit logging for issue and return transactions, accessibility, and defined response-time targets. Privacy analysis determines that the system should store only the student information required for lending and reporting.

Domain model and bounded contexts

The lending context owns reservations, loans, equipment condition, and overdue rules. The identity context owns authentication and institutional identity. A finance context may own payment or fine settlement. These contexts should not share a mutable database model merely for convenience. Integration events such as ReservationConfirmed and LoanReturned can communicate meaningful facts, while an anti-corruption layer translates identity and finance representations.

A Loan aggregate may contain its loan dates, status, and return information. Its invariants include: a loan cannot be returned twice; the due date must not precede the issue date; and a loan can be issued only to an eligible borrower. Reservation overlap may require coordination at the equipment level or a transaction strategy appropriate to the chosen architecture. The model must not assume that a simple in-memory check prevents concurrent requests in a distributed deployment.

Acceptance and traceability

For the requirement “prevent overlapping reservations,” acceptance tests should include adjacent non-overlapping dates, identical dates, partial overlap, cancellation, and concurrent requests. The requirement traces to student interviews and lending policy, to the reservation design, and to automated tests for overlap and concurrency behavior.

Outcome

The resulting backlog prioritizes search and reservation, staff issue and return, and auditability for the initial release. Recommendation features are deferred because they offer lower immediate value. The domain model clarifies vocabulary, exposes the difference between reservation and loan, and gives developers a stable basis for service and test design.

Learning points

1. Stakeholder language must be examined rather than copied uncritically.
2. Availability is often a rule or calculation, not a simple field.
3. Requirements, models, and tests should evolve together.
4. Bounded contexts prevent one overloaded concept from dominating all designs.
5. Compliance and audit requirements can affect both priority and architecture.

8. Professional Practice, Ethics, and Contemporary Developments

Requirements work has ethical consequences. A system may deny access, rank applicants, expose personal information, or automate decisions with significant effects. Analysts should identify affected groups, assess foreseeable harm, minimize data collection, document decision rules, and provide appropriate appeal or human-review mechanisms.

Accessibility should be considered during elicitation, not added only after implementation. Security requirements should address authentication, authorization, confidentiality, integrity, logging, recovery, and threat scenarios. Regulatory obligations vary by jurisdiction and domain; teams must obtain qualified legal and compliance advice rather than treating a generic checklist as legal assurance.

AI-assisted elicitation can summarize interviews, cluster feedback, generate candidate stories, or detect terminology differences. However, generated requirements may contain invented assumptions, omit minority viewpoints, reproduce bias, or expose confidential information. Human domain experts must verify outputs, preserve source evidence, and maintain accountability for decisions. AI-generated text should be treated as a draft, not as authoritative requirements.

Contemporary development increasingly uses executable specifications, continuous discovery, event storming, collaborative modeling, product analytics, and observability data. These techniques improve feedback, but measured behavior is not identical to user need: analytics can underrepresent users who abandon inaccessible or confusing systems. Quantitative evidence should therefore be combined with qualitative inquiry and ethical review.

Challenges and Limitations

Requirements are inherently uncertain because stakeholders discover needs through interaction with prototypes and early releases. Models are selective abstractions: they simplify reality and can become harmful if treated as complete. Prioritization scores can create false precision, especially when criteria are subjective. Traceability can become expensive and obsolete if it is maintained manually without clear value. Bounded contexts can introduce integration cost, and excessive domain modeling can delay delivery without improving decisions.

The practical response is not to eliminate uncertainty but to expose it. Record assumptions, test risky hypotheses early, revisit models, use lightweight artifacts where appropriate, and align the level of detail with the decision being made.

Best-Practice Checklist

• Identify stakeholders, viewpoints, affected groups, and decision owners.
• Separate goals, functional requirements, quality requirements, and constraints.
• Use domain language consistently and record disputed terms.
• Write observable, testable requirements with explicit exceptions.
• Validate requirements through review, prototypes, scenarios, and tests.
• Model entities, value objects, relationships, rules, and domain events only when they aid understanding.
• Define bounded contexts around coherent models and responsibilities.
• Trace important requirements to rationale, implementation, and verification.
• Prioritize transparently while preserving mandatory constraints.
• Reassess requirements and models as evidence changes.
• Protect privacy, accessibility, security, and human accountability throughout the lifecycle.

Chapter Summary

Requirements engineering discovers and manages the capabilities and constraints that define a software system. Functional requirements describe behavior, while non-functional requirements describe qualities and constraints that must be measurable or verifiable. Interviews, workshops, observation, document analysis, prototyping, surveys, and event analysis provide complementary elicitation evidence.

Use cases explain goal-oriented interactions and exceptions. User stories communicate user value concisely, while acceptance criteria establish testable completion conditions. Validation examines correctness, completeness, consistency, ambiguity, feasibility, verifiability, traceability, and priority.

Domain modeling creates a shared representation of entities, value objects, relationships, rules, and events. Domain-driven design adds strategic concepts such as core domains and bounded contexts, and tactical patterns such as aggregates, repositories, and domain services. Traceability connects goals to requirements, design, implementation, and tests. Prioritization makes trade-offs explicit but must not allow numerical scores to obscure legal or ethical obligations.

Effective practice is iterative and collaborative. Models and requirements are evolving tools for reasoning, not paperwork produced once and forgotten.

Key Terms

Requirement: A needed capability, condition, or constraint.

Stakeholder: A person, group, or organization affected by or interested in a system.

Functional requirement: A requirement describing system behavior or service.

Non-functional requirement: A requirement describing a quality, constraint, or operational condition.

Elicitation: The systematic discovery of stakeholder needs and constraints.

Use case: A structured description of interaction directed toward an actor’s goal.

User story: A concise statement of a user-valued capability.

Acceptance criterion: A testable condition required for a requirement to be accepted.

Domain model: A conceptual representation of important domain concepts and relationships.

Entity: A domain object defined by persistent identity.

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

Aggregate: A consistency boundary with an aggregate root.

Domain event: A significant occurrence in the domain.

Bounded context: A boundary within which a model and its terminology have consistent meaning.

Context map: A representation of relationships between bounded contexts.

Traceability: The ability to follow a requirement between its sources and lifecycle artifacts.

Prioritization: The process of ordering requirements according to agreed decision criteria.

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

Anti-corruption layer: A translation mechanism that protects one bounded context from another’s model.

Review Questions

Short Answer Questions

1. What is the difference between a functional requirement and a non-functional requirement?
2. Name four properties of a high-quality requirement.
3. What information is normally included in a use case?
4. Why are value objects often preferable to primitive data types for domain concepts?
5. What is the purpose of requirements traceability?

Long Answer Questions

1. Explain how interviews, observation, workshops, and prototyping complement one another during requirements elicitation.
2. Compare use cases and user stories, including the situations in which each is most useful.
3. Explain bounded contexts and analyze how they reduce ambiguity in a large system.
4. Describe domain-driven design’s strategic and tactical patterns and discuss their limitations.
5. Explain how non-functional requirements influence architecture, testing, and project trade-offs.

Analytical / Application Questions

1. For an online clinic booking system, identify five stakeholders, write three functional requirements, and write two measurable non-functional requirements.
2. Model the key concepts and invariants for a food-delivery order. Identify at least one entity, one value object, one aggregate boundary, and two domain events.
3. A team gives a compliance requirement a low weighted priority score but the product manager proposes deferring it. Analyze whether deferral is appropriate and identify the evidence and governance steps required before deciding.

Multiple Choice Questions with Answers

Question 1

Which statement is the best example of a functional requirement?

A. The system shall be available 99.9% of each month.

B. The system shall allow a customer to cancel an eligible order.

C. The system shall use encrypted database storage.

D. The interface shall conform to an accessibility standard.

Correct Answer: B. The system shall allow a customer to cancel an eligible order.

Question 2

Which quality makes a requirement verifiable?

A. It uses broad aspirational language.

B. It avoids measurable conditions.

C. A test, inspection, demonstration, or analysis can determine whether it is satisfied.

D. It is written only from the developer’s viewpoint.

Correct Answer: C. A test, inspection, demonstration, or analysis can determine whether it is satisfied.

Question 3

What is the primary purpose of acceptance criteria?

A. To define conditions under which a requirement is considered complete

B. To specify the programming language

C. To replace all stakeholder discussions

D. To describe the organization’s reporting structure

Correct Answer: A. To define conditions under which a requirement is considered complete

Question 4

Which concept is defined primarily by identity and continuity over time?

A. Value object

B. Entity

C. Acceptance criterion

D. Domain event

Correct Answer: B. Entity

Question 5

What is a bounded context in domain-driven design?

A. A database table shared by every subsystem

B. A boundary within which a model and terminology have consistent meaning

C. A list of non-functional requirements

D. A user-interface prototype

Correct Answer: B. A boundary within which a model and terminology have consistent meaning

Question 6

A user story is most appropriately understood as:

A. A complete database schema

B. A concise statement of a user-valued capability

C. A deployment script

D. A legal contract in executable form

Correct Answer: B. A concise statement of a user-valued capability

Question 7

Using S = 0.5V + 0.3R + 0.2U, what is the score when V = 4, R = 5, and U = 2?

A. 3.2

B. 3.6

C. 4.1

D. 4.8

Correct Answer: C. 4.1

Question 8

Which traceability direction checks that implemented features are justified by approved requirements?

A. Backward traceability

B. Lateral traceability

C. Random traceability

D. Prototype traceability

Correct Answer: A. Backward traceability

Question 9

Which technique is especially useful for discovering the difference between documented procedures and actual work?

A. Observation and contextual inquiry

B. Source-code compilation

C. Database normalization

D. Load balancing

Correct Answer: A. Observation and contextual inquiry

Question 10

What is the main responsibility of an aggregate root?

A. To expose every internal object directly to external clients

B. To enforce consistency rules within the aggregate boundary

C. To replace all repositories

D. To define the user interface layout

Correct Answer: B. To enforce consistency rules within the aggregate boundary