Iteration 3 Details for MPCS 51205

Each iteration will deliver an incremental accretion of work toward the final project deliverable.  Some assignments will require you to work individually and each team member will submit his or her deliverable, and other assignments will require you to work as a team and submit a single team deliverable.  Generally (see specifics within each Iteration), each student will be responsible for delivering some piece of the work (documentation, code, etc.).  You will be evaluated on the clarity and depth of your analysis of these and other deliverables.  "Deep Thinking" as well as "Shallow Thinking" are generally obvious.  Deep Thinking requires time and....thought.

Unless use of a tool is specified, you may take pictures of whiteboards, papers, napkins, etc. as submission artifacts.  From a remote collaborative design perspective, previous teams have happily leveraged free tools including excalidraw.com, which allows for collaborative brainstorming among remote team members.  However, some artifact deliverables will need to be in the form of formal models.  When a formal artifact is required, it will be so specified.

See the syllabus for information on grading.  Turning in Iteration assignments is required.  Submit your assignments as a tarball to the repository according to the directions on each Iteration page.

Iteration 3   Due: 5:00 pm, Monday, November 13, 2023

High Level Architecture and Initial Domain Model: 

Deliverable One:  Produce User Stories, focusing on a particular Microservice

Have each team member be responsible for one or more of the Microservices that you have identified in your Microservices Architecture Blueprint.  Each team member will choose one (or more) Microservices to "flesh out", and you should deliver a vocabulary representing the ubiquitous language of each Microservice.  Remember, these terms are high-level business terms that are central and critical.  This vocabulary will likely contain 10-20 entries (per microservice) and can be delivered in the form of a Word or Excel (or Mac Pages or Numbers) document.  For each term in the language, give a brief definition of it in terms of the context.  An example might be:  "Bid:  A bid is a binding contract that commits you to buy the item at the price you have offered, it if you win the auction." 

Next, consider the functional and technical requirements of the system, and your design of the high level architecture and communication among Microservices depicted in the Microservices Architecture Blueprint.  Based on the functional requirements of the system, you are to begin to write user stories to expand on the system requirements.  Each team member is responsible for drafting five user stories for a particular capability in your system (focusing on a particular microservice).  Your user stories will detail user intentions as well as system responsibilities. 

First, update your Service Operation Analysis deliverable from the previous iteration, now describing those user stories that will play a roll in the development of the microservice.

The user story verbiage should be a simple and direct description of one task or interaction of your microservice.  Focus on stories that implement an API-first approach to your microservice.  Your user stories should be based on the intentions of a user in a particular context.  Your user stories should be both meaningful and descriptive from the point-of-view of users in some role or set of roles as they derive value from a system that will  embody the purpose or intentions underlying the user interaction.  You may document your user stories however you wish, either (most simply) in a document of some form, or you may use any number of "free" Jira-like alternatives, such as trello.com or pivotaltracker.com.  You are of course welcome to use Jira itself, but that will cost money.

You may work collaboratively in developing your user stories, whiteboarding (and documenting) various design alternatives, but each team member will be responsible for the delivery of their individual user stories.  Your user stories should be based on the intentions of a user in a particular context.  Your descriptions should be both meaningful and descriptive from the point-of-view of users in some role or set of roles as they derive value from a system that will  embody the purpose or intentions underlying the user interaction.

Deliverable Two:  Produce Domain Models for your Bounded Contexts

Based on the functional requirements of the system and your developing user stories, prepare a preliminary list of candidate from your Candidate Class List and initial CRC cards and document a a first pass of the Domain Model for your Microservice(s).   Your depiction should become formal at this point and be produced in UML, using whatever tool you're most comfortable with, for example, Visual Paradigm.  Your architecture rendition should continue to include more key components and  interactions as your architecture takes on more form. It should also become more "realizable".

Deliverable Three:

Your team should begin the serious task of coding your microservice domains with this third iteration. 

Your team should begin coding your final project deliverable at this point, if you haven't already begun.  You will want to also produce some tests (coded by hand or developed using an existing harness such as junit, postman, etc.) that verify that your code is producing the results you wish. 

Look at your user stories, and domain models, and decide which parts of the system you should develop with this iteration.  The goal in about four weeks is to demonstrate before the class your auction system in all its glory.  You should continue to enhance the code that you developed for the rest of the quarter.

Your new code is not intended to be the final version of any of the classes you choose to implement.  Feel free to stub out whatever functionality you don't yet have time for or understand.  Your successive "code releases" are intended to represent an incremental expansion of the components of your microservices.

You may find the following online resources helpful as you work together to produce these deliverables:

Domain-Driven Design Reference
Domain-Driven Design Quickly
GitHub References Points on Domain-Driven Design
http://guide.agilealliance.org/guide/crc.html
http://agilemodeling.com/artifacts/crcModel.htm
http://css.dzone.com/articles/crc-cards-primer

You should also begin to contemplate your user HTML and REST-based interface.  You may find the following sites helpful:

http://getbootstrap.com/
http://learn.shayhowe.com/html-css/
http://www.codecademy.com/
You can find a quick index to UML diagrams here.


Deliverable Four:  Continue documenting your Architecture Decisions

Referring to Michael Nygard's documentation of ADR usage here and https://adr.github.io and https://adr.github.io/madr/, continue documenting your key architectural decisions.  You should store your ADRs in your github repository.
Submission:

For Iterations:

Have your designated Team Lead upload your team's IterationN files and any supporting materials to the repo. Please include a README text file that contains any instructions or additional details for the TAs to assist with grading.

Setup:

When you open the invitation URL in a browser tab, you will have to complete the following steps:

Github may ask you to grant permission for GitHub Classroom to have access to your GitHub account. If you are asked this question, you should say yes and grant access to Github Classroom.

You must click “Accept this assignment” or your repository will not actually be created. Do not skip this step!

If you run into any issues, please ask for help.