views:

163

answers:

3

This may be a basic question but I am pretty new to DDD. I have an domain object that we'll call Adjustment which can be processed in bulk from the UI. Before we process the Adjustments, we need to validate the date those adjustments will be applied. My problem is with the location of that IsValidDate() method in my domain object.

  1. Should it be a static method in the Adjustment class?
  2. Should it be part of an AdjustmentService class?
  3. Should I create a AdjustmentsGroup domain object to contain a collection of adjustments and which would also implement IsValidDate?

I would tend to think that the 3rd option is the best one but I have a hard time thinking of a domain term for the group of Adjustment objects. Is it ok to "force" a container type domain object for this type of scenario? Is there a common practice to handle this?

Thank you

Edit: IsValidDate actually contains business logic. This is not just a simple date validation method

+1  A: 

I would vote for 2) Make it a DomainService. The code to implement it could be in either a DomainServices class, an AdjustmentServices class, or a ValidateAdjustmentService class, depending on what other services are in the domain model, and what makes the most sense from an organizational perspective.

Another option, (if the rules implemented by this service are business rules) is to implement this as a SPECIFICATION. (Check out pages 224 - 240 in DDD)

Charles Bretana
Thank you for the answer. Validating the date is business logic (we are validating that we are the proper date range and not just that the date is a valid date) so I am wondering if picking 2) and taking this business logic out of the domain model is the wrong approach? Were you looking at the IsValidDate as business logic when answering or does that clarification affect your answer?
benoit
Read up on the DDD concept of a SPECIFICATION. A Specification is a predicate that determines if an object does or does not satisfy some criterion. It is and should remain a part of the Domain model, and should stay in the domain layer in your model.
Charles Bretana
+1  A: 

If you're doing simple is-this-actually-a-date string validation, the correct place for that method, in my opinion, is inside a Service class, as Charles suggested.

However, if data within the Adjustment or AdjustmentCollection objects can change the date validation logic, e.g. disallowing certain date ranges, the method belongs in that object.

iandisme
+1  A: 

I would favor the 3rd option, but create make a more generic function on Adjustment, like Validate(), which would return a collection of errors/validation faults on itself. That way you can add validation rules at a later time without changing your interface. The Validate() function of AdjustmentsGroup would simply call Validate() on each member in the collection. An equally valid (no pun intended) way would also be to have a separate validator class for the object that contains all validation logic.

Your AdjustmentService would then call Validate() on AdjustmentsGroup before processing the adjustments.

ericvg