빈혈 도메인 모델 피하기-실제 예

빈혈 도메인 모델 피하기-실제 예

---

나는 빈혈 도메인 모델을 이해하려고 노력하고 있으며 왜 그것들이 반 패턴인지 이해하려고합니다.

다음은 실제 사례입니다.

이름, 성별, 사용자 이름 등 수많은 속성이있는 Employee 클래스가 있습니다.

public class Employee
{
    public string Name { get; set; }
    public string Gender { get; set; }
    public string Username { get; set; }
    // Etc.. mostly getters and setters
}

다음으로 수신 전화 및 웹 사이트 문의 ( '리드'라고 함)를 영업 직원간에 균등하게 순환시키는 시스템이 있습니다. 이 시스템은 라운드 로빈 문의, 휴일, 직원 선호도 확인 등을 포함하므로 매우 복잡합니다. 따라서이 시스템은 현재 EmployeeLeadRotationService라는 서비스로 분리되어 있습니다.

public class EmployeeLeadRotationService : IEmployeeLeadRotationService
{
     private IEmployeeRepository _employeeRepository;
     // ...plus lots of other injected repositories and services

     public void SelectEmployee(ILead lead)
     {
         // Etc. lots of complex logic
     }
}

그런 다음 웹 사이트 문의 양식 뒷면에 다음과 같은 코드가 있습니다.

public void SubmitForm()
{
    var lead = CreateLeadFromFormInput();

    var selectedEmployee = Kernel.Get<IEmployeeLeadRotationService>()
                                 .SelectEmployee(lead);

    Response.Write(employee.Name + " will handle your enquiry. Thanks.");
}

저는이 접근 방식에서 많은 문제를 겪지는 않지만, 빈혈 도메인 모델 이기 때문에 비명을 지르며 실행해야 할 것입니다 .

그러나 나에게는 리드 회전 서비스의 논리가 어디로 가야하는지 명확하지 않습니다. 리드해야할까요? 직원에게 가야합니까?

순환 서비스에 필요한 모든 주입 된 저장소 등은 어떻습니까? 직원을 다룰 때 대부분의 경우 이러한 저장소가 필요하지 않다는 점을 감안할 때 직원에게 어떻게 주입됩니까?

---

이 경우 이것은 빈혈 도메인 모델을 구성하지 않습니다. Anemic Domain Model은 특히 개체의 유효성을 검사하고 변환하는 것입니다 . 예를 들어 외부 기능이 실제로 직원의 상태를 변경하거나 세부 정보를 업데이트 한 경우입니다.

이 경우에 일어나고있는 것은 모든 직원을 취하고 그들의 정보를 기반으로 그들 중 한 명을 선택하는 것입니다. 다른 사람을 검사하고 발견 한 것에 대해 결정을 내리는 별도의 개체를 갖는 것은 괜찮습니다. 객체를 한 상태에서 다른 상태로 전환하는 데 사용되는 객체를 갖는 것은 좋지 않습니다.

귀하의 경우 빈혈 도메인 모델의 예는 외부 방법을 갖는 것입니다.

updateHours(Employee emp) // updates the working hours for the employee

Employee 개체를 가져와 일주일 동안 근무한 시간을 업데이트하여 시간이 특정 제한을 초과하면 플래그가 발생하는지 확인합니다. 이 문제는 Employee 개체 만있는 경우 올바른 제약 조건 내에서 시간을 수정하는 방법에 대한 지식이 없다는 것입니다. 이 경우이를 처리하는 방법은 updateHours 메서드를 Employee 클래스로 이동하는 것입니다. 이것이 Anemic Domain Model 안티 패턴의 핵심입니다.

---

나는 당신의 디자인이 여기에서 괜찮다고 생각합니다. 아시다시피 빈혈 도메인 모델 안티 패턴은 도메인 객체에 코딩 된 행동을 피하려는 경향에 대한 반발입니다. 그러나 반대로 도메인 개체와 관련된 모든 동작이 해당 개체에 의해 캡슐화되어야 한다는 의미는 아닙니다 .

경험상 도메인 개체에 본질적으로 연결되어 있고 해당 하나의 도메인 개체 인스턴스 측면에서 완전히 정의되는 동작이 도메인 개체에 포함될 수 있습니다. 그렇지 않으면 책임을 명확하게 유지하기 위해 수행 한 것처럼 외부에서 공동 작업자 / 서비스에 배치하는 것이 가장 좋습니다.

---

모든 것이 머리 속에 있습니다. 회전 서비스를 도메인 모델의 일부로 간주하면 문제가 해결됩니다.

순환은 많은 직원에 대한 정보를 유지해야하므로 리드 나 단일 직원 개체에 속하지 않습니다. 그 자체로 도메인 객체가 될 자격이 있습니다.

"RotationService"의 이름을 "Organization.UserSupportDepartment"와 같은 이름으로 변경하면 명확 해집니다.

---

도메인 모델에 활동이 아닌 역할과 사물 만 포함되어 있다면 빈약 한 것입니다. 그러나 나는 객체가 아닌 모델 과 관련된 행동에 대해 이야기하고 있습니다 . 나는 다른 대답에서 그들 사이의 차이점에 대해 이야기합니다 ... https://stackoverflow.com/a/31780937/116442

귀하의 질문에서 내 처음 두 도메인 분석 모델링 규칙을 위반했습니다.

1. (기록 된) 활동으로 모델링 된 행동은 도메인 모델의 핵심입니다. 먼저 추가하십시오.
2. 도메인 활동을 메서드가 아닌 클래스로 모델링합니다.

모델에 "Enquiry"활동을 추가합니다. 이를 통해 모델에는 동작이 있으며 외부 컨트롤러 또는 스크립트 없이도 개체 그룹으로 결합하고 작업 할 수 있습니다.

참고 URL : https://stackoverflow.com/questions/2854801/avoiding-anemic-domain-model-a-real-example