우리는 처음으로 프로젝트에서 도메인 기반 디자인을 채택하려고합니다. 내가 가진 문제는 엔티티 간의 연관성입니다. 당신은 어떻게 그들을 올바르게합니까?DDD에서 연결을 구현하는 올바른 방법은 무엇입니까?
말하면, 간단한 일대 다 연관 인 Employee
및 Contract
엔티티가 있습니다. 어떻게 모델링합니까?
옵션 1 : 집계.
문제 : 문제는 올바르게 이해하면 집계 개체를 만들 때 집계의 모든 항목을로드해야한다는 것입니다. 엔티티의 저장소를 참조해야 할 필요가 있기 때문에 필요한 경우 엔티티를로드 할 수 없습니다. 그러나 매번 직원의 계약서를 데이터베이스에서 가져 오는 것은 큰 성능 문제가됩니다.
옵션 2 : 저장소 (예를 들어, ContractRepository.GetContractsForEmployee()
)를 사용하고 Contract
클래스에 EmployeeId
속성을 추가하여 직원의 계약을 가져오고 있습니다.
문제점 : 엔티티에 비즈니스 로직을 넣기가 어렵습니다. 내가 방법을 가지고 싶습니다, 말하자면, Employee.Dismiss()
,하지만 그것도 직원의 계약을 업데이 트해야합니다. 이것은 내가이 논리를 서비스에 넣어야한다는 것을 의미합니다. 문제는, 나는 단지 Employee
에서만 작동하는 많은 로직을 생각할 수 없다. 따라서 모델은 서비스 내에서 대부분의 로직을 사용하여 약간 빈약해진다.
DDD에서 이러한 문제를 어떻게 처리합니까?
DDD를 수행하지 않는 '간단한 일대 다 연관'을 생각하면 데이터베이스 스키마 디자인을 수행하고있는 것입니다. 엔티티 간의 연관성은 동작이어야합니다. 직원은 스스로를 해고 할 수 없으며 해고되어야합니다 (권한을 가진 다른 단체에서 해고해야합니다). 옵션 2가 올바른 옵션입니다. 엔티티에 대해 많은 동작이 필요하지 않습니다. 실제 도메인 비즈니스에서 도메인 객체가 매우 단순하다면 그렇게 할 수 있습니다. 도메인이 개념 (의미론)을 정의하고 오브젝트의 메소드 수를 정의하는 방법이 중요합니다. – MikeSW
MikeSW가 맞습니다. DDD의 중요한 측면은 유비쿼터스 언어입니다. 도메인에 관해 말하는 방법은 도메인 전문가가 도메인에 관해 말하는 방법이어야합니다. 그렇지 않으면 코드가 어색하고 직관적이지 않게됩니다. 그것은 사소한 것처럼 들리지만,이 권리를 얻으면 엔티티는 행동을 제안하기 시작합니다. 예 : Employee.Resign(); Contract.Terminate(); – Asher