Я использую Domain Driven Design в одном из моих ограниченных контекстов, и я использую методы Factory для создания своих агрегатов домена и обеспечения соблюдения моих бизнес-правил и инвариантов, но моя проблема в том, что иногда у меня есть большие агрегаты с множеством свойств, и большинство из этих свойств - это просто свойства данных, а не поведенческие, которые не влияют на состояние агрегата, поэтому использовать фабричные методы для заполнения всех этих свойств - кошмар. Пожалуйста, посоветуйте мне о том, как это сделать с помощью лучших практик?

public async Task CreateEmployeeAsync(CreateOrUpdateEmployeeInput input)
    {
        Guard.ArgumentNotNull(input.Employee, nameof(input.Employee));
        var employeeDto = input.Employee;
        Address address = null;
        if (employeeDto.Address != null)
            address = new Address(employeeDto.Address.Street, employeeDto.Address.City, employeeDto.Address.State,
                employeeDto.Address.Country, employeeDto.Address.ZipCode);

        var employee = Employee.Create(employeeDto.FirstName, employeeDto.LastName, employeeDto.Email,
            employeeDto.DateOfJoining, employeeDto.DepartmentId, employeeDto.EmployeeType,
            employeeDto.ReportTo, employeeDto.Title, employeeDto.AllowSystemAccess, address);

        //These properties are just data properties, they will not affect the state of the aggregate
        //This is a nightmare to fill each one hand by hand or even using Factory
        employee.MobilePhone = input.Employee.MobilePhone;
        employee.WorkPhone = input.Employee.WorkPhone;
        employee.MaritalStatus = input.Employee.MaritalStatus;
        await _employeeRepository.InsertAsync(employee);
    }
1
yo2011 14 Мар 2018 в 12:29

1 ответ

Лучший ответ

«Свойства данных», такие как мобильный телефон и рабочий телефон, являются частью состояния агрегата. И с ними связаны бизнес-правила. пример: номер телефона должен быть действительным. MaritalStatus может быть одним из 3 предопределенных значений, WorkPhone не требуется ...

Эти свойства необходимо проверить при создании объекта Employee. Что я могу предложить, так это добавить их в конструктор. В этом случае ваша модель предметной области имеет много свойств, и их невозможно избежать. Я не рекомендую что-то автоматическое, потому что это каким-то образом скроет некоторые свойства. Следующий разработчик, который будет работать с этим кодом, скажет: «Я не вижу, где установлен мобильный телефон», и это увеличит когнитивную нагрузку при работе с этой частью кода. Вам нужно будет знать о модели предметной области и автоматическом преобразователе или инструменте, используемом для автозаполнения свойств, чтобы понять, что происходит.

Иметь много свойств - не обязательно плохо. Если вы хотите улучшить свой совокупный дизайн, вы можете сгруппировать некоторые свойства в новый объект значения, если это имеет смысл для вашего бизнеса. Вы можете создать, например, объект значения ContactInfo, который будет содержать адреса электронной почты и номера телефонов.

1
Mohamed Bouallegue 14 Мар 2018 в 13:20