D788 Domain Driven Design is banner number ITSW 6105 and three competency units in the School of Technology, at the graduate level. The catalog lists its content unusually precisely: bounded context, context mapping, subdomains, entities, value objects, aggregates and aggregate roots. That list is effectively the assessment vocabulary, and using each term exactly as the discipline defines it is a large part of what separates a submission that clears from one that returns.
The model is a language before it is code
The premise of domain driven design is that most software failure is a translation failure. Business experts describe their work in one vocabulary, engineers build in another, and the gap fills up with misunderstandings that show up as defects nobody can attribute. The remedy is a model expressed in language both sides use, kept in the code and in conversation at the same time, so a change in one is visible in the other.
Bounded context is the central idea and the one most often used loosely. It is a boundary within which a term has one definition. Customer means something different to sales, to billing and to support, and the mistake is building one Customer that serves all three and satisfies none. Separate contexts, each with its own model, connected explicitly, is the design that makes the disagreement manageable instead of invisible.
Context mapping describes those connections and it has a vocabulary worth using correctly. A shared kernel is a deliberately common model two teams jointly own. A customer and supplier relationship means one context's needs influence the other's plan. Conformist means downstream simply accepts what upstream provides. An anticorruption layer translates at the boundary so a foreign model does not leak in. Each of these names an organizational relationship as much as a technical one.
Inside a context, the building blocks divide by identity. An entity is defined by identity that persists through change. A value object is defined entirely by its attributes and should be immutable, and treating money, a date range or an address as a value object rather than as loose fields removes a class of bug outright. An aggregate is a cluster with one root, and every change from outside goes through that root so the invariant holds. Getting these distinctions right is most of the technical grade.
Turning scored aspects into a model and a word budget
Aspects are scored one at a time at WGU and each needs a 2. In a modeling course they usually name the concepts directly, which makes mapping easy and precision the real risk: an aspect asking about aggregates will not accept a description of entities.
Budget it. Suppose nine scored aspects and a document of about 2,000 words with a context map and a model diagram. Nine into 2,000 is 222 each. Sort them. Two are artifact aspects answered by the diagrams, needing 130 each of reading text, which is 260 and releases about 180. Two cover subdomain and bounded context identification, at 320 each, or 640. Two cover aggregate design and invariants, at 320 each, or 640. One covers the context map relationships, 250. Two shorter framing sections take 90 each, which is 180. That totals 260 plus 640 plus 640 plus 250 plus 180, which is 1,970, on target, and the four heavy sections carry two thirds of the document.
Before drafting, build a glossary from your scenario: every domain term, its definition, and the context it belongs to. Terms that need two definitions are showing you a context boundary, and the glossary becomes evidence for the aspect that asks how you identified them.
On the D788 modeling task?
Send the aspects and the domain scenario. You get a glossary, a context map with named relationships and an aggregate design with invariants.
The vocabulary, used exactly
| Term | The test that identifies it | The common misuse |
|---|---|---|
| Subdomain | A part of the business problem space, core, supporting or generic | Used as a synonym for a module in the solution |
| Bounded context | A boundary inside which one term has exactly one meaning | Treated as a deployment unit rather than a linguistic one |
| Entity | Two of them can have identical attributes and still be different things | Any class with a database table |
| Value object | Two with identical attributes are interchangeable, and it never changes | Left as loose primitive fields on an entity |
| Aggregate | A consistency boundary changed as one unit | Any group of related objects |
| Aggregate root | The single object outside code is allowed to hold a reference to | The largest class in the group |
| Context map | The named relationships between contexts and the teams behind them | A diagram of components with unlabeled lines |
The middle column is what to apply to your own model. Each of these is a test with a yes or no answer, and running the tests produces the justification an aspect will ask for.
Evidence, glossaries and citation in a modeling paper
The evidence in a domain model is linguistic. Quote the domain expert or the scenario document where a term appears, and show how the model uses that same word. Where two sources use one word differently, quote both, because that contradiction is the strongest possible evidence for a context boundary and it cannot be invented convincingly.
Aggregate design needs its invariant stated explicitly. An order aggregate that must never have a total inconsistent with its lines is a boundary with a reason. Without a stated invariant, an aggregate is just a grouping, and an aspect asking you to justify it has nothing to score. Keep aggregates small and reference other aggregates by identity rather than by object, since large aggregates create contention and are the standard beginner error.
For sources, the foundational texts on domain driven design and the published patterns for strategic design are the strong citations, in APA where your program requires it. Use the terms as those sources define them, and where you adapt a pattern, say so rather than redefining a term quietly. Conference talks and engineering blogs are useful as examples of application and weaker as definitions.
What clears, and what returns
WGU records Competent or Not Competent, with revision available without penalty when an aspect falls short. In a six month flat rate term that revision costs days, and in a vocabulary-heavy course most returns are precision problems that a glossary pass would have caught.
Papers that clear derive contexts from language rather than from convenience, name the relationship type on every edge of the context map, state an invariant for every aggregate, and use value objects where identity does not matter. They distinguish core subdomains, where the business differentiates and deserves the effort, from generic ones that should probably be bought rather than built.
Returns come from four patterns. One model serving the whole business, which is the situation the discipline exists to fix. Aggregates that are large object graphs with no stated invariant. A context map with lines and no relationship names. And terms used interchangeably, particularly entity for aggregate and bounded context for module.
Six mistakes that cost D788 students time
- One universal model. A single shared definition of every term is precisely what bounded contexts exist to avoid.
- Aggregates that are too large. A root holding hundreds of children is a contention point and usually a sign the invariant was never identified.
- Ignoring value objects. Money, ranges, addresses and identifiers modeled as loose primitives lose their rules and scatter validation.
- Unlabeled context map edges. The relationship type is the content. Lines without names carry no information.
- Designing from the database. A model derived from tables inherits the storage vocabulary rather than the business one.
- Treating every subdomain as core. Effort should follow differentiation, and saying which parts are generic is part of the analysis.
How we work on this course
Support for D788 is vocabulary and boundary work. Send the scored aspects and the domain scenario and you get a glossary built from the case with the contradictions marked, a context map with relationship types named, an aggregate design with the invariant stated for each root, and a model paper in the register WGU graduate evaluators expect. Where a section of your course is assessed by an objective assessment, our work is preparation only, and objective assessments are proctored: we never sit or assist during one and never ask for or use your portal credentials.
Modeling papers reward precision more than length. In a six month flat rate term, the hours saved by running a glossary pass before drafting are hours the next course gets.
Three questions D788 students ask
Is D788 the same course as ITSW 6105?
What is the difference between an entity and a value object?
Do bounded contexts have to become separate services?
Where D788 sits in WGU's programs
The July 2026 catalog places this code in 1 current WGU program. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.