Course Description
Team Project
Milestones
Sprint 2: Domain

Sprint 2: Domain

Make sure to address feedback from Sprint 1.

The goal is this iteration is to build your Domain classes i.e., classes and data structures that model the problem that you’re solving. Examples of domain classes would be Recipe class and custom RecipeList for your recipes application, or a Model class to hold the state of the card game that your users are playing.

You will wire these up to your user interface, and add “test data” so that your application is interactive, within the context of this hard-coded data. You are not expected to have a functional database or service yet. However, you should have the “pipeline” in place that loads data from the model and passes it up to the UI layer.

  flowchart LR
  Model("Model with fake data") --> Domain("Domain Classes") --> VM("View Models") --> View("Views")

Finally you should write unit tests that cover your user interface classes and domain classes. Unit tests will be expected for all code that you write from this point forward in your project.

How do you work around “missing” components i.e., how do you display data when you don’t have a data class to read the data? You create mock classes for components that you haven’t implemented yet. These mock classes provide hard-coded test data for your unit tests, and make it easier to write tests for classes that are in-progress. They allow you to finalise the interface and build out the implementation over time.

In this sprint, you should expect to write mock classes for your Data layer. Other implementation layers should use and display this data as-if it were live data.

Requirements

For this sprint, you should complete the following:

  • You should have a layered architecture with UI, Domain and Data layers (expecting the Data layer to be empty, except for test classes).
  • In your Domain package, add data classes (business objects) relevant to your project e.g., Recipe class for a Recipes application; Post class for a social media application. Also add a Model class that loads and manipulates your domain objects as necessary.
  • Your Model should load fake data, ideally from a MockDB object (which substitutes for a “real” database).
  • Your application should be interactive and “mostly work” at this stage - with fake data.
  • You should have a “reasonable number” of unit tests in place against your User Interface and Domain classes. These unit tests should pass.

Submission

After the demo, you will need to ensure that your work is complete so that it can be graded. This means that all documentation should be updated (issues, wiki pages, team meeting minutes), and all source code should be frozen (changes pushed, everything merged to main).

The deadline is 6:00 PM on the listed time and date. You do not need to actually submit anything; we will grade what is posted in your GitLab project at the deadline.

The content that is in GitLab should be the same as what you presented in-class. You are allowed to make small corrections but please avoid making major content changes between the demo and the submission.

Grading

The grading scheme is available in Learn under Resources > Rubrics .

Deliverables are normally graded by the following week’s lecture, and the grade and feedback will be posted under Submit > Dropbox . Any questions related to this should be sent directly to your TA.

See grading policies for more information.