resource lookup for entity construction in DDD

Question

I am fairly new to DDD and here is my dilemma:

I have to persist an entity A that has a reference to entity B (let us consider both are entity roots). The UI layer gathers all these info (at controller) through A_DTO (DTO class for A), maps the attributes to a new instance of A from the DTO, now for the reference to B in A , UI sends an id. As I am using an ORM behind the repositories I would want to lookup for the object instance of B from BRepository , populate the reference on the new A instance that we are building and finally call ARepository.save(A instance).

I have a few options here

1. Do all these in UI layer(either in controller or some kind of service facade) or
2. Do this in a ApplicationService called createA or even a domain Service .

Which of options will be correct ??. Here what really stands out is the process of looking up of B by its id to get the reference to set on A object, this can be equally argued as process to keep ORM satisfied or to keep the domain model consistent. There might be some implicit business rules and validations around the process of setting reference of B on A, these I think are the driving points for the decision here.

Also what could queer the pitch further here will be a consideration for validations, should validations be weaved in the process of creation of an entity and say the constructors and/or setters through specific errors that can be bubbled to the client through UI and have another level of validatins through repos ?? or as an explicit step happening in the controllers ??

Answer 1

The DTO is merely a convenience class for transporting data within the UI layer. The fact that you use an ID to refer to B is an implementation detail of the UI layer. So it should be the job of the UI layer / controller to map the DTO to a domain object, including translating IDs to references.

Validation, on the other hand, belongs rightly in the domain layer. In this regard, the only job of the UI is to set values in the domain object and display any errors arising from this.

Answer 2

Both options can be viewed as correct, but I tend to prefer option 2 because the encapsulation provided by application services helps in reading and understanding the code. It also makes it easier to consolidate the API of your domain. The argument in favor of option 1 over 2 is that the additional layer of encapsulation resulting from use of application services is needless complexity, though of course you be the judge. Validation is usually manifested in several layers of a application, including the presentation layer and the domain layer. It seems ideal to write validation logic once and have it reused everywhere else, in practice it is usually easier to duplicate validation logic. That means the the presentation layer, such as ASP.NET MVC, has its own validation declarations for view models. Then the application service and domain entities should also perform any validation that is needed in that context. Take a look at my posts on services in DDD as well as validation in DDD for in depth discussion on these topics.