The biggest difficulty I am having is finding where to house the responsibilities of each object identified by me in the system( say on problem space). I am posting a very simplified description of a feature in library management system.
- As a admin, I can add books to the inventory, or change the "states" of the book to any permissible value.
- As a staff, I can change "states" of the book only to "Returned" or "Borrowed".
- As a Customer, I can view all the books with states "Returned" or "Borrowed".
- Book can be of following states "Returned", "Borrowed", "Removed",
- As a admin, I can grant or revoke access to staff for adding a book to any staff
- User Repository
- Book Repository
Library holds User Repository and Book Repository in one to one relationship, Repository has their corresponding entities in one to many relationship.
- Gets list of all user/ a user of interest respective to problem domain.
- Saves User entity to external system(Database or Cloud)
- Gets list of all Book/ a book of interest respective to use case.
- Saves Book entity to external system(Database or Cloud)
- Add a book
- For the Usecases 3 and 5, where to add access based logic. In the our case, to decide whether user (Only admin) object has access to grant/revoke access for adding book. And list of books to be returned based on user role.
NOTE: I want to achieve
- cohesion among entities
- unit test each module with 80-90% coverage
- Incase of application layer, how do you ensure current/new team members don't expose the domain objects directly