비즈니스 로직이 포함 된 저장소 패턴

Question

DDD를 기반으로하는 데모 애플리케이션을 작성할 의향이 있습니다. 리포지토리에서 Entity Framework ORM을 사용하면 모든 것이 훌륭합니다. MVC 및 Windows Forms 응용 프로그램은 저장소 메서드를 호출하며 작동합니다. 그러나 Dapper 나 NHibernate로 Entity Framework를 대체하기로 결정했거나 데이터가 웹 서비스를 통해 제공된다면 어떻게해야합니까? 나는 repostiory 구현을 다시 작성해야하지만, 내 bussines 논리와 함께 무엇을 필요가있다. 비즈니스 로직은 이제 저장소에 저장됩니다. 일부 예제에는 비즈니스 로직이 컨트롤러에 있지만 둘 이상의 클라이언트가 있습니다. Repository 위에 레이어를 배치해야합니까? DDD의 개념에서 그 층의 이름은 무엇입니까?

Answer 1

필자는 repostiory 구현을 다시 작성해야하지만 내 탈 상용 논리는 무엇을 사용해야 하는지를 이해해야합니다. 비즈니스 로직은 이제 저장소에 저장됩니다.

이런 종류의 걱정이됩니다. 비즈니스 로직이 리포지토리에 배치되면 도메인 기반 디자인을 전혀 연습하지 않습니다. DDD에서 비즈니스 로직은 도메인 엔티티에 있습니다. 저장소의 목적은 단순히 채워진 도메인 객체를 반환하는 것입니다. Domain Objects는 데이터베이스, XML 파일 또는 방금 생성 한 동적 저장 여부에 관계없이 저장 방법을 알 수 없습니다.

도메인 기반 디자인의 모든 목적은 특정 인프라에 묶이지 않도록하는 것입니다. Entity Framework 또는 Dapper를 사용하는지 여부에 관계없이 도메인 객체가 작동 할 수 있어야합니다.

Answer 2

일반적으로 도메인 모델을 나타내는 클래스 집합을 만들 수 있습니다. 그런 다음, 읽기/쓰기를위한 도메인 모델 클래스를 취할 저장소에 대한 클래스 세트를 갖게됩니다. 이렇게하면 다른 것과 독립적으로 하나를 변경할 수 있습니다. 예를 들어

, 도메인 모델 :

class Vehicle 
{ 
    string id; // or you can use an appropriate key 
    int noOfWheels; 
    int topSpeed; 
    // etc. 
} 

class Car : Vehicle 
{ 
    int passengerCapacity; 
    int trunkCapacity; 
    // etc. 
    string Serialize(); 
    void Deserialize(string representation); 
} 

그리고 저장소 :

class VehicleRepository 
{ 
    void Store(Vehicle v); 
    Vehicle GetVehicle(string id); 
    void Delete(string id); 
    // etc. 
} 

내가 코드를 간결을위한 인터페이스를 추가 피했다. 그러나 일반적으로 이러한 종류의 구조는 저장소와 관계없이 도메인 개체를 수정할 수있게하며 반대의 경우도 마찬가지입니다. 따라서 객체를 직렬화/역 직렬화하여 객체를 NOSQL 저장소 (또는 로컬 테스트 용 파일 시스템)에 넣을 저장소를 가질 수 있지만 SQL 저장소에서 객체를 CRUD하는 다른 저장소를 가질 수 있습니다.

대부분의 경우에 사용되는 개체에 serialization/deserialization 메서드가 포함되었습니다. 그러나 때로는 별도의 클래스로 분리하여 물리적 저장 매체 (예 : 물리적 표현은 변경 될 수 있지만 도메인 객체는 영향을받지 않아야하며 반대의 경우도 있음)를 사용하여 버전 관리를 위해 저장소 뒤에 숨겨져 있어야합니다.