Iteration 3 Details for MPCS 51221

Each iteration will deliver an incremental accretion of work toward the final project deliverable.  Generally (see specifics within each Iteration), each student will be responsible for delivering some piece of the work (documentation, code, etc.).

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

Iteration 3   Due: 5:00 pm, Tuesday, November 14, 2017

Continuation of Design, Code, and Test:

Consider the functional and technical requirements of the system, and your design of the high level architecture.  Based on the functional requirements of the system and your initial use cases, use stories and current domain model your second requirement for this iteration is some actual code and tests that implement some portion of your domain model.  You are to work collaboratively in developing your models, whiteboarding (and documenting) various design alternatives, finally delivering an updated high level microservices architecture and supporting domain models that will represent your "updated model" and code.  Your code base should just now be beginning to take fundamental shape, and your tests should be running and verifying that fact.

If there are any Essential Use Cases and stories left undefined, each member of the team is responsible for (like in the first iterations) individually delivering one additional Use Case and dependent stories  fleshed out from the model.  These will detail user intentions as well as system responsibilities.  The verbage should be a simple, general, abstract, technology-free and implementation-independent description of one task or interaction of the system you envision.  In writing your use cases and stories, try your best to avoid any inherent assumptions about the underlying technology implementation and the user interface. Your use cases should be based on the intentions of a user in a particular context, rather than on the concrete implementation by which the purpose or intention might be carried out.  Your use case description 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.

High Level Architecture and Initial Domain Model: 

You will have two weeks to produce this third iteration.  You are to work together as a team on these deliverables except when you are instructed to individually deliver something.

Considering the functional and technical requirements of the system (to be named by the class as a whole), envision the high level microservices architecture and domain models. 

Deliverable One:  Microservices Architecture Blueprint

Leveraging your Context Map and Domain Vision Statement and your first pass at a high-level architecture, produce a draft of a Microservices Architecture Blueprint.  This is a draft-only drawing of the Microservices that you envision (at this point in your thinking) in the final system.  This can and should be quite high-level, and shouild look something like this snippet:

snippet

As a team, continue your development of your high level microservices architecture model of your proposed solution.  This model will be a continuation of the "rough sketch" of your "current architectural approach", becoming much more refined during this iteration.  Your depiction should become formal at this point and be produced in UML, in something like Visual Paradigm or whatever tool you've chosen, along with the artifact drafts I've mentioned in class (see below).  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".   Specifically, your architecture should now demonstrate your plan for incoroporating microservices and in particular messaging.  You should include technologies that you enivion will come into play within the different microservices (the technology stacks).  Notice that each microservice has its own datastore, and its own technology stack.  There is nothing wrong with using several common frameworks and tools within the microservices.  Your goal is neither to produce a polyglot Tower of Babel nor a singular technology stack reproduced across all microservices, but rather, choosing the right stack for the right job (ie. microservice as a bounded context implementing a core business capability).

Deliverable Two:  Define Your Messages & Services Model

Based on the functional requirements of the system and your developing use cases and stories, use Visual Paradigm (or whatever you've chosen) and the following artifacts from Lecture 5:

Microservice Architecture Catalog
Service Operation Analysis
Service Operation Decomposition
Technology Stack Decomposition
Event Model

to follow the API-FIRST principle and describe the central messages that will be passed between the various services and services and components in your model.  Feel free to modify the five artifacts above to suit your team's needs.  They are intended to help you as a team think and communicate about what you are going to build.

Specifically, what messages will be passed from one service to another asychronously over RabbitMQ?  What messages should be passed in a synchronous fashion, perhaps via RPC/RMI/gRPC or a RESTful interface?  What patterns might you leverage in your communication (e.g., Request/Reply)?  This messaging model does not need to be complete (or final), but it does need to depict your understanding at the moment of the services you have identified along with their responsibilities, and relationships.  You are to work collaboratively in producing this inital model, whiteboarding various design alternatives, finally documenting the current state of your model in UML in Visual Paradigm and the above artifacts.

Deliverable Three:  Third Iteration of Use Case Model, Revised User Story Map & Revised Iteration Plan

Modify your team use case/story models to reflect the planning changes you encounter.  Additionally, each member of the team is responsible for (as in the first and second iterations) individually delivering one new Essential Use Case  fleshed out from the model, along with dependent user stories.  These will detail user intentions as well as system responsibilities.  As in the first two exercises, the verbage should be a simple, general, abstract, technology-free and implementation-independent description of one task or interaction of the system you envision.  Try your best to avoid any inherent assumptions about the underlying technology implementation and the user interface yet to be designed.  Your use cases should be based on the intentions of a user in a particular context, rather than on the concrete implementation by which the purpose or intention might be carried out.  Your use case description 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 Four:  Code

You should begin the serious task of coding some aspect of your solution with this third iteration.  Ask yourself how you wish to approach this construction activity.  Do you want to do a "risk-based" approach where you code out the riskier parts of the system?  Or do you want to do a "value-first" approach that attempts to deliver the code that you consider to be the most valuable to the customer (Professor Shacklette)?  You will want to also produce some tests (coded by hand or developed using an existing harness such as junit, etc.) that verify that your code is producing the results you wish.

Your approach should be first to determine whether your planning will be risk-based or value-based.  Then, look at your use cases, story map, and any class models you may have already designed, and decide which microservices you should focus on and begin to develop with this iteration.  Next, again looking at your use cases, story map, and developing class models, begin to design the domain model within one or more microservices.  Decide which supporting classes you should develop with this iteration, and which microservice they belonng to.  These classes may be focused on your user interface, or they may be focused on some other domain model from some other microservice you've decided upon.   The goal in two weeks is to demonstrate before the class what your code is doing (an interface, however fledgling, may be demonstrated, or a messaging microservice).  You may also continue to enhance any code that you developed for the second iteration.

One approach might be to code what "is easiest that you know best at the moment."  This might be the front-end user interface.  For this you might consider runninng an httpd docker conainer and coding the HTML interface in that microservice.  By the time we have covered RMI, RabbitMQ and MySQL, you will have all the building blocks (with the exception of MongoDB) necessary to begin produce a solution.

Your new code is not intended to be the final version of any of the microservices or classes you choose to implement.  Feel free to stub out whatever functionality you don't yet have time for or do not yet understand.  This "code release" is intended to represent an incremental expansion of central classes and supporting classes.

You can find a quick index to UML diagrams here.