Overview
- MVP scope and usable workflows
- Small features across service boundaries
- Shared message and data contracts
- Integration checks, ownership, and demo readiness
Make The Approved Project Usable
A minimum viable product is a working version of the approved project's essential user workflows, sufficient to demonstrate its purpose
- Select essential behavior from the approved proposal
- Connect it through the existing App, MQ, API, and DB VMs
- Keep the Logging System and authentication/authorization working as features grow
- Distinguish a working workflow from a mock screen or disconnected component
- Record unfinished work honestly rather than hiding it behind a successful screenshot
Begin with a small complete workflow from the approved proposal, including its required admin CRUD scope
The slide below: identify which required features must remain working
Use The Proposal's MVP Scope
Required For The MVP
- Authenticated and authorized admin web CRUD for named team-owned records
- The user stories mapped to MVP goals in the approved proposal
- Working logging and account behavior from the completed milestones
Required Across The Semester
- Profile updates and admin account/role maintenance pages
- Meaningful external API integration and useful transformed data
- Include these in the MVP when the approved proposal maps them there; preserve the remaining final-demo scope
All internal VM-to-VM requests, results, status, and errors use RabbitMQ, including API-to-DB work
Follow One User Action Through The Services
Illustrative project: a signed-in user searches an external catalog and saves an item to their account
| Step | Responsibility | Observable result |
|---|---|---|
| Search | App requests work through RabbitMQ | A request is associated with the waiting user action |
| Retrieve | API worker calls the external source | Relevant fields are transformed into project data |
| Save | DB worker handles the MQ request | A record is associated with the authorized user |
| Reply | The result returns through RabbitMQ | App shows success only after the confirmed result |
| Verify | Reopen the saved list | The saved record is still present for its owner |
This illustrates a vertical slice: one complete user behavior through the relevant layers; it does not require every project to have a catalog
Agree On The Interface Before Parallel Work
A message contract defines the agreed meaning and shape of an operation's request, result, and failures
- Name the operation and the data each participant needs
- Define request/reply correlation and the expected result
- Identify the service that verifies account permissions and changes stored data
- Decide what a timeout, invalid request, duplicate request, or external-service failure means
- Put the agreement in the existing issue or shared documentation before splitting implementation
Message fields consumed by other services are shared interfaces; internal variable names can differ
Keep Only Useful External Data
- Identify which external fields the user workflow needs
- Validate and transform them in the API VM
- Store useful project data through the DB worker when persistence is needed
- Define what the App should show when data is missing or unavailable
- Follow the source's limits and attribution requirements for the API the team selected
For the catalog example, a stable external identifier, title, and display data may be useful; storing the entire raw response does not establish a useful data model
Reuse A Working Path Before Adding A Framework
Shared Behavior
- Publish a request and match its reply
- Validate incoming messages
- Check the current user's access
- Record a secret-free event or error
- Show a consistent result to the user
Feature-Specific Behavior
- The operation and relevant fields
- The rule for this action
- The data changed or returned
- The user's success or failure message
Extract repeated behavior when another feature actually needs it; preserve each service's responsibility
Verify Behavior And Its Boundary
| Check | What it establishes |
|---|---|
| Successful action and reload | The result works and required data persists |
| Invalid input | The service rejects an unacceptable request |
| Unauthorized user | Another user's protected data cannot be changed |
| Missing or late reply | No unconfirmed success is reported |
| External source unavailable | A stated safe result is shown |
| Logs and state match | The observed outcome can be traced across VMs |
Reuse the existing logging and account checks while testing new features; do not log credentials or sensitive session values
Plan One Complete Feature
- Choose a user workflow from the approved proposal
- Identify its input, participating VMs, stored or external data, and visible result
- Write its acceptance checks in the team issue
- Name the teammate responsible for each task and agree on its interface
- Each teammate links their task issue to the pull request that merges their work
Use the optional MVP work-plan template or update the existing project board and documentation directly
The plan supports the current project; it is not a separate graded submission
Prepare A Repeatable Demo
- Start from a known state and show the actual working user workflow
- Recheck registration, login, protected access, and logging after integration
- Use test data and keep credentials out of the recording
- When practicing the demo, have each member speak briefly about their concrete work or tests
- State known limitations and show the clearest supporting issue/PR evidence
- Check the assigned MVP and recorded Project Showcase checklist and due time for Module 6
The independent midterm assessment remains a separate Module 5 responsibility
Knowledge Check
Questions
- What is a working version of the approved project's essential user workflows that demonstrates its purpose?
- What describes one complete user behavior across the relevant system layers?
- What agreement defines the meaning and shape of a request, result, and failures?
- What does a timeout establish about an operation's success?
Answers
- A minimum viable product
- A vertical slice
- A message contract
- Success has not been confirmed; do not report an unconfirmed operation as successful
Use Next to reveal each answer
Key Terms And Further Learning
- Minimum viable product: the essential working version of the approved project
- Vertical slice: a complete user behavior across relevant layers
- Message contract: the agreed meaning and shape of an operation's request, result, and failures
- Revisit the approved proposal, required architecture, Logging System, and authentication/authorization requirements
- Further learning: official documentation for the API, database, and messaging libraries the team actually uses
Summary
- Build small, complete workflows from the approved proposal
- Preserve the existing service boundaries and shared utilities
- Verify success, rejection, authorization, and unavailable dependencies
- Record ownership, reviewed changes, and honest demo readiness