mercredi 11 novembre 2015

How to properly model calculatable data, that look like the part of the model in DDD?

I am becoming a big fan of DDD. So, I'm thinking of applying it correctly to my current system I develop.

Suppose we have two aggregate roots: Order and User. Order has two properties, referencing the User: owner and contractor. Owner created an Order, contractor fulfilled it.

Owners can rate the quality with which the Order was fulfilled by the contractor. So we have an Feedback entity, connected to Order, containing rating.

Now, User object contains an average rating of each user across the orders he fulfilled. And this part confuses me a little.

User rating is not just a static property, but actually an average of all ratings across Feedbacks. And it is changed (needs to be recalculated) at the moment an Order has Feedback attached.

Currently I have some services encapsulating domain logic: OrderService and UserService (I know this is actually not in compliance with DDD, but I will refactor that later). When OrderService receives a command to attach Feedback to order, it emits OrderFeedbackAttachedEvent which UserService listens for to recalculate user rating.

What doesn't satisfy me is that the knowledge about Order aggregate root is now leaked into UserService. And I don't see the way to escape it. I'm starting to think there should be some pattern to handle such cases.

Rating seem to be a perfect property of the user. But the fact that it is not a static, persistent value, but rather something, that is calculated based on other objects data, makes me doubt.

Rating isn't itself an entity either. Neither it is a value object. What is it, I wonder, in DDD? And how do I model ratings (or any other calculatable value) in my system without sacrificing performance and ease of use)?

Aucun commentaire:

Enregistrer un commentaire