2

In one of the products I work with we have an aggregation root with a lot of domain logic, and now I have a requirement to make one small piece of behavior configurable.

To give an example, let's say I have an entity and this entity has many schedules, these schedules tells me if they are on time or not and they have different ways of doing that according to their type (polymorphism), one of these specifications needs to take into account a database configurable parameter giving me the result.

Now, all of the possibilities I thought doesn't seems right

  1. It doesn't makes sense to remove domain logic from the domain just because of this requirement.

  2. Also there's no way for the Entity to access a repository, at least not one considered right by DDD

I thought of a lot of other ways of solving that, but I always end up having to manually instantiating the repository inside the entity or having my application layer to inject this configuration values by property which breaks the design since there's no way of forcing the value to be injected before a method that may use it being called.

What alternatives do I have here?

Improve this question
4
  • Why not inject the repository inside that specification class? – Constantin Galbenu Feb 8 '17 at 0:47
  • @ConstantinGALBENU how would I do that with an entity beeing retrieved from the DB (MongoDB int this case)? The other option would be injecting via method, but then I would need to add the parameter to the base class and inject the repository even when not needed. – bateloche Feb 8 '17 at 0:59
  • The entity is loaded by an repository that reconstructs it and it's schedules. When the repo is reconstructing the schedules, it could inject that configuration or inject a service that reads that configuration – Constantin Galbenu Feb 8 '17 at 1:27
  • "there's no way of forcing the value to be injected before a method that may use it being called" ??? Why can't the method be implemented in a way it checks if the related configuration value was provided beforehand, and otherwise throw an exception? – Doc Brown Feb 8 '17 at 8:44
2

Remember that a repository gives you access to an aggregate root. If you are trying to access another repository from an entity you are basically trying to break out of you aggregation. This is typically an indication that your entity is not really a domain entity, or at least this aspect of what you are trying to do is not. It's a responsibility that perhaps needs to be delegated.

Perhaps the determination of schedules is better off in some scheduler service either as a domain service (living in the same aggregate) or in your application layer.

If the scheduler is a domain concept. The configuration value could just be obtained through an abstract service (implemented with a query object) within the same aggregate. It doesn't necessarily have to be a repository (you are just reading a value, there is no collection semantics here).

If the thing you are trying to do is really awkward to do through some scheduler service then you could access it using double dispatch on your entity (accept it as a parameter as you mentioned).

Improve this answer
1
  • --> It doesn't necessarily have to be a repository (you are just reading a value, there is no collection semantics here). Just nailed it here, my mistake was thinking that just because it accesses data it should be a repository. – bateloche Feb 8 '17 at 17:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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