5

Thanks in advance.

I have some Aggregates in the Domain Layer library. Also, some DTOs in a separate library, which is shared between Server and Client side.

An Aggregate of an entity is more informative than its DTO. So, in order to convert from DTO to Aggregate, a repository should be accessed by a Dto Assembler. Interfaces of repositories are in Domain Layer. That's why i come to conclusion that DtoAssembler should be a part of DomainLayer.

Is this right?

Andrey K.
  • 665
  • 8
  • 29
  • Thanks for your answers. I'm still trying to put it all together. I edited my question a little bit. I ment that DtoAssembler dictates what methods a repository should have. And the interface of the repository is in DL. That's why i started thinking of DtoAssembler being a part of DL... – Andrey K. Nov 24 '15 at 15:57
  • 1
    My mistake was that i wanted to use a _DtoAssembler_ to convert a _Dto_ to an _Aggregate_. Thanks to the answers, i got that it is best to do the convertion and the apply in the _Application Services_. – Andrey K. Nov 27 '15 at 10:16

2 Answers2

9

No, this would be plain wrong in the context of DDD.

Try asking a (non-technical) domain expert what he thinks about the DTO assembler. He will look with large, questioning eyes at you.

DTOs (and consequently their assembler) are a technical concept - they define the data structure in the context of a specific interface to your system.

Repositories mostly return aggregates. If you query the database for statistical data that is not modeled in your domain, then a repository may also return an immutable data object. Just make sure that you're not accidentally missing a domain concept when doing that.

Once you have the data from a repository (no matter whether it is an aggregate or a data object) you can feed it into the DTO assembler.

theDmi
  • 17,546
  • 6
  • 71
  • 138
  • Thanks! A DtoAssembler takes an IRepository in order to convert a Dto to an Aggregate, right? Am i right that a DtoAssembler should be "clever", that it should not only get the Aggregate, but also apply changes to it? (It's because it may happen that the data in Dto differs from the data of retrieved Aggregate, whereas the Id is the same...)...? – Andrey K. Nov 25 '15 at 09:47
  • I'd keep the DtoAssembler simple and do all non-trivial stuff in the application service. This way, the DtoAssembler just takes the inputs it requires to construct a DTO, applies transformation where necessary (e.g. serialization) and then returns the DTO. – theDmi Nov 25 '15 at 10:03
  • Thanks, i like this idea :), and what about the other way around, the transformation from Dto to Aggregate? I probably had a misleading idea that DtoAssembler should also be able to transform from Dto to Aggregate... – Andrey K. Nov 25 '15 at 10:10
  • 2
    Directly converting a DTO to an aggregate does not make sense in most cases. Are you sure you want to use DDD? It sounds a lot like you're building a CRUD-style app. I suggest you read about DDD application services. They are meant for the things you try to do in the DtoAssembler. – theDmi Nov 25 '15 at 10:15
2

Not necessarily, in my opinion. Since you are using a layered architecture, I assume your DTOs reside in an upper layer -- commonly the service layer - that acts as the communication point between server and clients. Indeed, the main purpose of the DTOs as their name imply (Data Transfer Objects) is to enable for communication, transfering the information without any kind of logic attached - eg. operations.

Layers should only know those located beneath, not above; thus, the DTOs should be kept in the service layer and be consumed by whoever is responsible - for instance, a command processor - in order to retrieve the domain objects from a repository and perform whatever operations are involved.

Bottom line: DTOs don't apply to the domain, they belong to service / communications.

jnovo
  • 5,659
  • 2
  • 38
  • 56
  • Thanks! You provided the example of a command processor. This made me think that the transition Dto->Aggregate and Aggregate->Dto could be done in the ServiceLayer avoiding DtoAssembler. Do you think it woud be a better approach then having a "clever" DtoAssembler, which should not only be able to get the Aggregate, but also apply changes to it? (it may happen that the data in Dto differs from the data of retrieved Aggregate, whereas the Id is the same) – Andrey K. Nov 25 '15 at 09:58
  • 3
    The DtoAssembler should be as dumb as possible, normally it would just map fields from one object to another - for instance, between your aggregate and your DTO. – jnovo Nov 25 '15 at 10:24