How to apply business rule in DTOs DDD

Question

I need to apply business rules in a DTO, but this DTO has properties of N entities.

I wanted to know the correct way to validate this DTO.

You shouldn't have business rules in your DTOs, if you want to make sure that they are collating the correct data items from several entities, I'd do that in a Unit Test against a DTOMapping service. — Matthew Cawley, Feb 04 '17 at 12:21
You do **not need**, you **decided** to. There absolutely **no reason** to want to validate your DTO against business rules, or there is something wrong in your design. **Details** your **background** and your **expectations** to get a proper answer. — Boris Guéry, Feb 06 '17 at 19:28

score 0 · Answer 1 · answered Feb 05 '17 at 05:16

Very common approach would be to wrap DTO into an Entity and implement business rules inside the Entity.

var state = new DTO();
var entity = new Entity(state);

//this will change the state in a consistent way according to business rules
entity.DoSomething1();
entity.DoSomething2();

//this is C#, so I can't get immutable version easily, but if your language allows that - you should return immutable state from entity. Or you can return a clone of the state
state = entity.State;

//store or do whatever you like with the state as long as you keep it immutable.
_repository.Save(state);

score 0 · Answer 2 · answered Feb 05 '17 at 08:49

As DTO is just a data-transfer-object, it should never apply any business logics inside.

DTO has properties of N entities

The preferable way is to create an aggregate class for your case and apply business logics inside.

public class Entitity1
{
}

public class Entity2
{
}

public class EntityAggregate
{
    public EntityAggregate(Entity1 entity1, Entity2 entity2) // constructor
    {
        this.entity1 = entity1;
        this.entity2 = entity2;
    }

    public ExecuteYourBusinessCase()
    {
        ... access entity1 and entity2 here and evaluate business logics
    }
}

Also it's worth metioning that one of DDD ideas is to prevent creating of invalid objects. So your should guarantee that if domain entity has been created it is valid and DTO can always be created. Business logics remains a black box for the layer responsible for DTO creation

score 0 · Answer 3 · answered Feb 07 '17 at 12:47

As already stated in other answers:

You shouldn't have business rules in your DTOs.

Although, when the topic is DDD, another very common approach to ensure that you'll always create valid domain objects is to use the Builder Pattern.

This pattern allows you to vary a product's representation. For example, a software may have a domain denominated Product, but - in real world representation - it may be a Service or a Material (I can sell a cellphone or a cellphone insurance), so two builders must be created (MaterialBuilder and ServiceBuilder, for ie) that builds the same domain object, the Product.

This pattern generally is used with a method chaining and leads to a fluent interface.

How to apply business rule in DTOs DDD

3 Answers3