WGU D780 Software Architecture and Design Task 1 | Complete Design Patterns and Python Code Refactoring Exemplar with Detailed Explanations and Tested Code | 2026/2027 Updated .

WGU D780 | TASK 1 WORKED EXEMPL AR 2026/2027 RESEARCH EDITION




WGU D780 – Software
Architecture and Design

Task 1: Design Pattern Analysis and Python Code Refactoring | 2026/2027
Research Edition

October 2026




Research findings and assessment alignment

Part I — Software design and architecture analysis

Part II — C2-style design-pattern selection and justification

Part III — C3-style Python refactoring implementations

Part IV — Testing and verification

Part V — GitLab organization and evidence

Part VI — Refactoring evaluation and architectural trade-offs

Part VII — Conclusion

Part VIII — References

Final assessment-alignment review




Original worked exemplar — official rubric not fully verified.




Research findings and assessment alignment

This research-based worked exemplar incorporates the publicly available D780 course description and
student reports published between July 2025 and June 2026.




Independent study resource • Not an official WGU assessment 1

,WGU D780 | TASK 1 WORKED EXEMPL AR 2026/2027 RESEARCH EDITION



The official October 2026 WGU Institutional Catalog identifies D780 as Software Architecture and
Design (ITSW 5103), covering architectural styles, design-pattern selection and implementation, and the
design of reliable, secure software systems.

Assessment-specific evidence from students includes:

• On January 1, 2026, a student described Task 1 as a Python-focused design-pattern recognition and
refactoring assignment.
• On June 15, 2026, a student reported a C3 revision because their refactored code did not implement
the patterns identified earlier. A student who had passed explained that C3 should contain three
refactored snippets implementing the patterns selected in C2.
• A student reported organizing their implementation into three separate Python files in GitLab, each
identifying its chosen pattern. This is useful implementation evidence, not an independently verified
file-naming requirement.



Verified coverage versus unknown requirements

Area Verification status

D780 course and design-pattern competencies Officially confirmed

Task 1 involves Python design-pattern recognition and Supported by student reports
refactoring

C2: Identify replacement patterns for components Supported by passed-student report

C3: Refactor three snippets using the patterns selected Supported by passed-student report
in C2

GitLab workflow Supported by student reports

Exact scenario and original three snippets Not recovered

Full A–C1 requirements and remaining rubric Not recovered

Specific design patterns required by WGU Not established



Scope of this document: Because the original three code snippets and complete rubric remain
unavailable, the material below is a complete, original technical worked example of the confirmed C2–C3
workflow. It is not a reconstructed official WGU submission, and its selected patterns must not be
represented as the actual prescribed answers.




Part I — Software design and architecture analysis


1. Introduction
Software design patterns provide reusable solutions to recurring structural and behavioral problems. They
support software development by organizing responsibilities, reducing dependencies, and improving the
capacity of systems to accommodate changing requirements.




Independent study resource • Not an official WGU assessment 2

, WGU D780 | TASK 1 WORKED EXEMPL AR 2026/2027 RESEARCH EDITION



A recurring problem in poorly structured applications is the concentration of unrelated behavior within a
single module or class. Such designs frequently rely on conditional statements, direct construction of
concrete dependencies, or tightly coupled communication between components.

Although these implementations may satisfy immediate functional requirements, they can make software
increasingly difficult to maintain as new business rules and integrations are introduced.

This worked example examines three independently designed components of a fictional retail platform:

1. Pricing and discount calculation.
2. Shipping-provider creation.
3. Inventory-level notification.

The example demonstrates how identifying a specific weakness, selecting an appropriate pattern, and
implementing that pattern can improve maintainability without sacrificing required functionality.



2. Architectural principles
Four object-oriented design principles guide the analysis.

Single Responsibility Principle (SRP). A module should have a focused reason to change. Pricing
policy, shipping-provider creation, and inventory notification should not be concentrated within a single
class.

Open/Closed Principle (OCP). Software components should accommodate new behavior through
extension where practical, rather than requiring repeated modifications to stable logic.

Dependency Inversion Principle (DIP). High-level business logic should depend on abstractions, such
as interfaces or protocols, rather than directly depending on concrete implementations.

Encapsulation. A component should expose a well-defined interface while keeping implementation
details internal, reducing the potential for accidental misuse.

These principles are design objectives, not absolute rules. Introducing abstractions without a meaningful
need can create additional complexity.



3. Selected design patterns
The three patterns selected for this original example are:


Component Selected pattern Category Primary design benefit

Pricing engine Strategy Behavioral Interchangeable discount
algorithms

Shipping service Factory Method Creational Decoupled creation of
shipping-provider objects

Inventory tracker Observer Behavioral Notification of interested
components when stock
changes meet defined
conditions




Independent study resource • Not an official WGU assessment 3