5

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.

Usecase

  1. As a admin, I can add books to the inventory, or change the "states" of the book to any permissible value.
  2. As a staff, I can change "states" of the book only to "Returned" or "Borrowed".
  3. As a Customer, I can view all the books with states "Returned" or "Borrowed".
  4. Book can be of following states "Returned", "Borrowed", "Removed",
  5. As a admin, I can grant or revoke access to staff for adding a book to any staff

Entities

  1. User
  2. User Repository
  3. Book
  4. Book Repository
  5. Library
  6. Permission

Associations

Library holds User Repository and Book Repository in one to one relationship, Repository has their corresponding entities in one to many relationship.

Behaviour

  1. User Repo:

    • Gets list of all user/ a user of interest respective to problem domain.
    • Saves User entity to external system(Database or Cloud)

  2. Book Repo:

    • 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

Question

  1. 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
Improve this question
1
  • Leave a comment on reasoning for down-voting the question which would help in improving the question specific.
    – Mani
    Commented Dec 4, 2017 at 4:57

1 Answer 1

Reset to default
1

I think the standard way is to ignore all these auth rules when creating the business logic and then simply to append a standard role based authentication system to the application afterwards.

For example, if the app is a webpage you would simply prevent non staff users from accessing the 'change state of book' page

Improve this answer
7
  • 1
    Yup, the business classes shouldn't be enforcing access logic. That's more the responsibility of the presentation tier of the application.
    – Greg Burghardt
    Commented Dec 4, 2017 at 15:19
  • @Ewan: Thats my question, where do we place prevent non staff users from accessing the 'change state of book' page this logic?
    – Mani
    Commented Dec 5, 2017 at 1:18
  • in the application layer. the exact place depends on what you're​ making, language, framework etc
    – Ewan
    Commented Dec 5, 2017 at 8:18
  • @Ewan: From self descriptive design perspective & enforcing future developers not to touch the domain models directly and to be done only via application layer how can be achieved? There might be a chance where future/junior intern can expose the domain model without surpassing via application layer.
    – Mani
    Commented Dec 7, 2017 at 4:50
  • that is true. But what we generally find is that the rules such as those outlined in your use case are not in fact system requirements. Rather the requirement is 'the system should have role based auth' and the rules are the initial setup of that auth. You might well have processes such as backup or reporting which ignore those rules or have new roles introduced. To treat them as defining, always respected rules of the system is incorrect and immediately causes problems
    – Ewan
    Commented Dec 7, 2017 at 4:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.