Clean Architecture - "Users" Kata

General Description

Functional Requirements

• Display list of users.
• Add a new user.
• A user must contain name, email, and password as required fields.
• Email must be a valid email.
• Password must be at least 8 characters, with at least one letter and one number.
• The app should show an error if trying to add two users with the same email.
• Extra Challenge:
  • Add address as part of the required information for the user (address, zip code, city).
  • Only one user per domain can exist (1 user with gmail, etc...).

Development Platform

• The UI will be a command line or terminal app.
• All data in memory, no persistence between executions.
• The data source could be an API or Database in the future.
• The UI could change in the future to a web app, mobile app, or desktop app.
• Business rules must be validated through unit tests.
• In tests, dependencies will be replaced by manual fake dependencies.
• Equality tests must also be created for value objects and entities.
• Use MVP for the presentation layer.

Part 1 - Entities

• Define entities and value objects.

• Business rules must be tested by creating unit tests.

• Rules:

  • The user must have name, email, and password as required fields.
  • Email must be a valid email.
  • Password must have a minimum length of 8 characters, have at least one letter and one number.
  • Two instances of the same email must be equal.
  • Two instances of the same password must be equal in a comparison.
  • Two instances of user, with the same id, must be equal in a comparison.

• Extra Challenge:

  • Add address as part of the required information for the user (address, zip code, city).

Part 2 - Use Cases

• Define the use cases, repositories for:
  • Displaying list of users.
  • Adding a new user.
• Application rules must be tested by creating unit tests.
• In unit tests, you can use manual fake objects.
• Rules:
  • The application must not allow adding two users with the same email.
• Extra Challenge:
  • Only one user per domain can exist (1 user with gmail, etc...).

Part 3 - UI

• Create a console application that invokes the use cases.
• Use MVP
• Define the presenter and the UI
• The presenter must be conditioned by the UI it adapts

Part 4

• Modify the app to have persistence between executions using a database, locally stored file, or another solution. Maintain the domain and presentation layers without modifications.
• Replace the console or terminal UI with a technology of your preference, keeping the domain and data layers unmodified.
• Only the corresponding adapters should change and the composition root if necessary.
• Add address as part of the necessary information for the user (address, zip code, city) and create the necessary tests.
• Only one user per domain can exist (1 user with gmail.com, 1 user with outlook.com, etc.) and create the necessary tests.