Search code examples
domain-driven-designmicroservices

How to Break same Entity but different microservice domains

I'm facing an case with my new microservice application.

I have an Entity as users (An single table, but different roles).

consider i have roles as manager and reader, And one more entity as Book.

Where the manager can assign Books to readers, And i have Microservices as usermS, bookmS.

When i want to get all the readers of Book-A, the API will go in to bookmS, but the user details are still with the usermS.

And also combined searches.

I'm more worried about the paginations and search for the readers, if the readers for a Book keeps increasing. Expected to get roles in future.

Solution

  • Lets first break down your problem:

    start with the easy one:

    When i want to get all the readers of Book-A, the API will go in to bookmS, but the user details are still with the usermS.

    your doubt here is how to show the user details from the bookms?

    there are two options :

    1. When some user becomes a reader of your book save user name and email type of details in the reader object in bookms so that you could shown them , also listen to event of user detail change from userms so that you could update the readers.

    good part here is that there is no dependency between userms and bookms. bad part here is that you may need to update multiple reader entity when a user detail changes, small optimizations here is just update in the read model.

    1. get data first from bookms and then from userms .

    good part : no event listening , always consistent data. bad part: high dependency between bookms and userms and And also combined searches.

    i would have gone with the first approach assuming user dosen't change the basic details on which you need to show data very frquently.

    SECOND QUESTION:

    How to break the system using DDD?

    In this the first answer written given right direction to it. i just want to add a bit more.

    You should consider manager and reader as entity in bookms and not as roles. Reason from DDD and in general: In General: A user could be managing a book and as well a reader . DDD: Manager and Reader are notions which bookms (which actually should be named libraryms ) are part of the domain entity.

    So your solutions would be:

    userms :

    user: person which has access to library and can apply for being a manager or a reader. there could be two roles - student , admin .

    libraryms: Manager Entity - users which are allowed to subscribe a book to readers. ReaderEntity - any user which has taken a book subscriptions BookEntity - represents a book registered in the library BookSubscriptionEntity - its your choice, you could use the BookEntity but i would prefer this.

    Now by separating the role as admin and manager as entity you achieved two things.

    One is now a admin could be a reader as well and a student can be a manager as well.Also library microservice works according to DDD , easy to understand and some api like assign book to reader dosent need to check anyhthing from userms