Форма DTO: плоская, сложная/вложенная или смесь обоих

У меня есть n-ярусное приложение MVC2 (DAL, Domain, Service, MVC web) с использованием DDD-подхода (Domain Driven Design), имеющего модель домена с репозиториями. Мой сервисный уровень использует шаблон Request/Response, в котором объекты Request and Response содержат DTO (объекты передачи данных) для маршалирования данных с одного уровня на следующий, а отображение выполняется с помощью службы AutoMapper. Мой вопрос таков: какая форма должна принимать DTO? Может ли она иметь вложенную/сложную DTO или должна быть строго плоская проекция? Или, возможно, смесь обоих? Кроме того, каковы основные причины наличия плоской DTO против более сложного/вложенного DTO?

Например, предположим, что у меня есть домен, такой как:

public class Employee
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public Company Company { get; set; }
}
public class Company
{
    public string Name { get; set; }
    public string Address { get; set; }
    public string City { get; set; }
    public string State { get; set; }
}

Существует три разных способа моделирования объекта Response.

Вариант 1 - опция DRYest:

public class GetEmployeeResponse
{
    public class EmployeeDTO { get; set; } // contains a CompanyDTO property
}

Из исследования, которое я сделал, было бы нецелесообразно, чтобы DTO принимал аналогичную форму как предмет домена, как показано выше.

Вариант 2 - сплющенная проекция области (anti-DRY):

public class GetEmployeeResponse
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string CompanyName { get; set; }
    public string CompanyAddress { get; set; }
    public string CompanyCity { get; set; }
    public string CompanyState { get; set; }
}

Это проще, так как DTO, по-видимому, должен быть, но в конечном итоге делает больше DTO.

Вариант 3 - смесь обоих:

public class GetEmployeeResponse
{
    public EmployeeDTO Employee { get; set; }
    public CompanyDTO Company { get; set; }
}

Это позволяет коду быть немного более сухим, многоразовым и управляемым, а также не раскрывает мою доменную структуру конечному пользователю. Другое главное преимущество заключается в том, что другие ответы, такие как GetCompanyResponse, могли бы просто вернуть CompanyDTO, не создавая копии всех этих свойств, аналогично варианту 2. Что вы думаете? Какой вариант этих (если есть) вы взяли и/или сработали для вас? Если эти запросы/ответы позже будут отображаться как методы службы WCF, изменится ли ваш ответ?

Ответ 1