D786 Microservices Design and Architecture is banner number ITSW 6103 and three competency units in the School of Technology, at the graduate level. The catalog says the course has students analyze a business's needs and demonstrate knowledge of microservice design and architecture, and the order of that sentence is the instruction. Analysis of the business comes first, service design follows from it, and a decomposition proposed without the business analysis behind it has skipped the part the aspects are written around.
Boundaries are the whole problem
Everything difficult about microservices is boundary placement. Split in the wrong place and every feature request touches four services, three teams have to coordinate to ship it, and you have paid the full cost of distribution for none of the benefit. Split in the right place and each service changes for one reason, owned by one team, deployable alone. The technology is the easy part; the analysis that decides where the seams go is the graded competency.
Business capability is the usual basis for that analysis, which is why the catalog puts business needs first. A capability is something the organization does that has its own rules, its own vocabulary and its own reason to change: ordering, billing, fulfillment, identity. Splitting by technical layer instead, so that one service holds all the data access and another all the logic, produces components that cannot be deployed independently and have not solved anything.
Data ownership is the decision students most often defer and least often can. Each service owning its own data is what makes independent deployment real, and it immediately raises the hard question: what happens to consistency across services. Distributed transactions in the traditional sense are usually not available, which pushes you toward eventual consistency with compensating actions, and toward accepting that a query spanning several services is now a design problem rather than a join.
Communication style follows. Synchronous calls are simple to reason about and couple availability, since a service is only as available as everything it calls in line. Asynchronous messaging decouples availability and introduces ordering, duplication and the need for consumers that can handle the same message twice. A graduate paper is expected to choose per interaction rather than globally, with a reason for each choice.
Turning scored aspects into services and a word budget
Aspects at WGU are scored one at a time and each needs a 2. Here they usually divide into analysis aspects and design aspects, so sort them first, because the analysis ones require evidence from the business scenario and the design ones require argued decisions.
Budget it. Suppose twelve scored aspects and a document of about 2,200 words with a service diagram. Twelve into 2,200 is 183 each. Sort them. Three are artifact aspects answered by the diagram and a service table, needing 110 each of framing, which is 330 and releases about 220. Two are the business analysis, at 300 each, or 600. Two justify the decomposition and the data ownership model, at 320 each, or 640. Two cover communication and resilience patterns, at 250 each, or 500. One covers deployment or operational implications, 180. Two are short framing sections at 50 each, or 100. That totals 330 plus 600 plus 640 plus 500 plus 180 plus 100, which is 2,350, so trim the resilience sections to 200 each and the paper lands near 2,250, with analysis and decomposition still holding more than half.
Before writing, list every service with the one reason it would change and the data it alone owns. Any service with two unrelated reasons to change is two services, and any data item owned by two services is a boundary error you will otherwise defend by accident.
On the D786 decomposition?
Send the aspects plus the business scenario. You get a capability analysis, a service table with ownership, and the argument for each boundary.
Seven questions that test a proposed boundary
| Question | A good answer | What a bad answer means |
|---|---|---|
| Why would this service change? | One business reason, stated in domain language | Two reasons means two services |
| What data does it alone own? | A named set no other service writes | Shared writes mean the boundary is fictional |
| Can it be deployed alone? | Yes, with a versioned contract | Coordinated release means you have a distributed monolith |
| Who owns it? | One team, end to end | Shared ownership recreates the coordination you split to avoid |
| What happens when a dependency is down? | A defined degraded behavior | Cascading failure means availability was never decoupled |
| How chatty is it at the seam? | Coarse-grained calls carrying what the caller needs | Many small calls per operation signal a badly placed seam |
| Does a common query span it? | Answered by a view or a copy maintained deliberately | Joining across services at request time is a boundary in the wrong place |
Run all seven against each proposed service before writing a word. The answers become your justification section, and the failures become the redraws you would otherwise have made after a return.
Patterns, precision and graduate sourcing
Distributed systems have a vocabulary of named patterns and using them precisely is part of the grade. A circuit breaker stops calling a failing dependency to let it recover. A bulkhead isolates resource pools so one slow dependency cannot consume every thread. Retries need backoff and a cap, and they need the operation to be safe to repeat. A saga coordinates a business transaction across services with compensating actions rather than a shared lock. Naming one of these where you mean another is exactly the imprecision graduate evaluators look for.
Acknowledge the costs honestly. Distribution buys independent deployment and scaling and charges in operational complexity, network failure modes, harder debugging across service boundaries, and consistency that is no longer free. A paper that presents the style as a straightforward improvement has failed the trade-off expectation even if every technical statement is correct.
For sources, established texts on microservices and domain modeling, published work on distributed systems trade-offs, and engineering experience reports are the strong material, cited in APA where your program requires it. Experience reports should be labeled as single-organization accounts. Where your business scenario supplies volumes, team structure or regulatory conditions, quote them when you justify a boundary so the decomposition is visibly derived from the case.
What clears, and what returns
WGU records Competent or Not Competent with no letter grades and no ordinary grade point average, and a returned performance assessment can be revised and resubmitted freely. Inside a six month flat rate term the expense is days, so the objective is a first submission where every boundary has an argument attached.
Papers that clear analyze the business before proposing anything, name the capability behind each service, assign data ownership explicitly, choose communication style per interaction, and state the operational cost the organization is accepting. They also say where they would not split, which demonstrates that the decomposition was a judgment rather than a default.
Returns come from four patterns. A decomposition by technical layer rather than by capability. Services that share a database, which removes the independence the whole style exists for. Resilience patterns named without saying which failure each addresses. And an analysis section that describes the business without deriving a single boundary from it.
Six mistakes that cost D786 students time
- Splitting by layer. A data service and a logic service must be deployed together, which is a monolith with network calls inside it.
- Sharing a database. Two services writing one schema are coupled at the deepest possible level regardless of how the code is organized.
- Assuming distributed transactions. Consistency across services is a design problem to be solved with compensation, not a feature to be assumed.
- Synchronous chains. Each hop multiplies failure probability and latency, and a chain of five is an availability calculation nobody did.
- Retrying unsafe operations. Retries need the operation to be safe to repeat, or the retry creates duplicates the business will see.
- Omitting the operational cost. Deployment, monitoring, tracing and on-call across many services is the bill for independence, and a paper that hides it is advocacy.
How we work on this course
D786 support is boundary analysis. Send the scored aspects and the business scenario and you get a capability breakdown drawn from the case, a service table with change reasons and data ownership, the seven-question test run against each proposed boundary, a communication and resilience plan chosen per interaction, and a model paper in the register WGU graduate evaluators expect. If your course carries an objective assessment, readiness work is the whole of what we do there. Those assessments are proctored, so we are not present for any part of one, and portal sign-in details are never requested.
Decomposition papers get long when the boundaries were never tested and short when they were. In a six month flat rate term that difference decides whether this course shares the term with another one.
Three questions D786 students ask
Is D786 the same course as ITSW 6103?
How many services should my design have?
Should I recommend microservices for every scenario?
Where D786 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.