CODEWITHSUNDEEP
domain-driven-designdto
Mohsen
Mohsen

Reputation: 4266

How to convert a DTO to Domain Objects

I'm trying to apply ubiquitous language to my domain objects.

I want to convert a Data Transfer Object coming from a client into the domain object. The Aggregate's Constructor only accepts the required fields, and the rest of parameters should be passed using aggregate's API even when the Aggregate is being created(by say CreateAggregate command).

But the DTO to Aggregate mapping code becomes a bit messy:

if(DTO.RegistrantType == 0){
    registrantType  = RegistrantType.Person()
}
elseif(DTO.RegistrantType == 1){
    registrantType  = RegistrantType.Company()
}
//.....
//.....
var aggregate = new Aggregate(
        title,
        weight,
        registrantType,
        route,
        callNumber,
    )

//look at this one:

if(DTO.connectionType == 0){
    aggregate.Route(ConnectionType.InCity(cityId))
}
elseif(DTO.connectionType == 1){
    aggregate.Route(ConnectionType.Intercity(DTO.originCityId,DTO.DestinationCityId)
}
//..........
//..........

One thing I should mention is that this problem doesn't seem a domain specific problem.

How can I reduce these If-Else statements without letting my domain internals leakage, and with being sure that the aggregate(not a mapping tool) doesn't accept values that can invalide it's business rules, and with having the ubiquitous language applied?

Please don't tell me I can use AoutoMapper to do the trick. Please read the last part carefully.'

Thank you.

Upvotes: 0

Views: 1999

Answers (2)

Batavia
Batavia

Reputation: 2497

So why don't you use more inheritance

for example

class CompanyRegistration : Registration {

}

class PersonRegistraiton : Registration {

}

then you can use inheritance instead of your if/else scenario's

public class Aggregate {
  public Aggregate (CompanyRegistration) {
     registantType = RegistrantType.Company();      
  }

  public Aggregate (PersonRegistration p) {
     registrantType = RegistrantType.Person(); 
  }


}

you can apply simmilar logic for say a setRoute method or any other large if/else situations.

Also, i know you don't want to hear it, you can write your own mapper (inside the aggegate) that maps and validates it's business logic

for example this idea comes from fluentmapper

var mapper = new FluentMapper.ThatMaps<Aggregate>().From<DTO>()
                    .ThatSets(x => x.title).When(x => x != null).From(x => x.title)

It isn't too hard to write your own mapper that allow this kind of rules and validates your properties. And i think it will improve readability

Upvotes: 1

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57387

A typical answer would be to convert the DTO (which is effectively a message) into a Command, where the command has all of the arguments expressed as domain specific value types.

void doX(DTO dto) {
    Command command = toCommand(dto)
    doX(command)
}

void doX(Command command) {
    // ...
    aggregate.Route(command.connectionType)
}

It's fairly common for the toCommand logic use something like a Builder pattern to improve the readability of the code.

if(DTO.connectionType == 0){
    aggregate.Route(ConnectionType.InCity(cityId))
}
elseif(DTO.connectionType == 1){
    aggregate.Route(ConnectionType.Intercity(DTO.originCityId,DTO.DestinationCityId)
}

In cases like this one, the strategy pattern can help

ConnectionTypeFactory f = getConnectionFactory(DTO.connectionType)
ConnectionType connectionType = f.create(DTO)

Once that you recognize that ConnectionTypeFactory is a thing, you can think about building lookup tables to choose the right one.

Map<ConnectionType, ConnectionTypeFactory> lookup = /* ... */

ConnectionTypeFactory f = lookup(DTO.connectionType);
if (null == f) {
    f = defaultConnectionFactory;
}

Upvotes: 2

Related Questions