0

I have gone through few posts like THIS and THIS, etc. but I couldn't clarify a confusion with respect to design that's in my mind. What would be the best practice to add CRUD for related entities when working with micro services? (my question is generally related to microservices, but currently I'm using aspboilerplate, to be specific)

For instance, I have an entity Product having around seven to ten properties in it. And then we may have another entity ProductContract. Each product can have multiple contracts added/updated.

Question: is it a good idea to create a separate Application Service for ProductContract entity? as it is going to have it's own input/output Dtos and logic, etc.

OR

It is better to create a ProductContractManager and keep its logic there. Then inject this manager into Product Application Service? This way, Product Application Service would have methods like 'AddProductContract', 'UpdateProductContract', etc.

Zeeshan
  • 2,884
  • 3
  • 28
  • 47

1 Answers1

1

The main driver of whether ProductContract should be owned by a different service is the consistency requirements, because achieving stronger levels of consistency between microservices is difficult (especially without tying the services together at the DB level: if going down that way, the decision to have separate microservices should probably also be revisited). So the main question you want to ask is, if updating/deleting a Product can there be a window of time where that update/delete isn't reflected in ProductContract (and vice versa)?

If the answer to that is that it can't, then you'll save yourself a lot of trouble by just putting responsibility for ProductContract in the same service that has responsibility for Product. If eventual consistency is allowed, then a separate service might be called for: the consideration there isn't really technical but more related to human organization (who will be developing and maintaining the functionality) and expectations around whether ProductContract and Product will evolve together (functionality changes in one being likely to also lead to functionality changes in the other).

Levi Ramsey
  • 18,884
  • 1
  • 16
  • 30
  • This answer helped me to understand one thing but rasied a question, reasonable scenario which I faced ATM is that what if update product not require update Contract but delete for sure yes. Is delete call from one micoservice to another BREAK the microservice architecture? – user2304483 Aug 21 '22 at 06:15