공장 패턴 DDD에 어디에 있어야합니까?

Question

나는 이것을 잠시 동안 논했지만 지금도 결론에 도달하지 못했습니다. 응용 프로그램 계층에있는 팩토리 코드가있는 대부분의 예제는 도메인 계층에 있어야한다고 생각하는 경향이 있습니다. 이유 : 때로는 모든 팩토리 생성을 원하는 공장에서 초기 유효성 검사를 수행하는 경우가 있습니다. 이 코드를 내 개체의 모든 인스턴스에 사용하고 싶습니다. 경우에 따라 생성자에 부 자연스러운 느낌을주는 매개 변수 정보가 필요한 작업이 있습니다. 몇 가지 더 중요한 이유가 아닙니다.

왜 이것이 나쁜 습관입니까? 다른 패턴이 손상됩니까?

Answer 1

+1. 내게 필요한 옵션이 좋은 이유가 될 수 있습니다. 최소한 도메인 모델 계층과 유사하게 작성 코드를 유지합니다. 그렇지 않으면 도메인 모델의 사용자는 제한된 액세스 생성자를 찾을 때 특별히 인스턴스화하는 방법을 혼동하게됩니다. 실제로 분리해야하는 한 가지 중요한 이유는 동일한 사물을 만드는 데 유효한 여러 가지 방법이 있다는 것입니다. 이것은 추상적 공장을 고용 할 때 보통의 경우입니다.

분리해야한다면 예를 들어 (자바의 경우) 적어도 도메인 모델의 동일한 레벨의 패키지와 항상 함께 배송합니다.

upper 
    --> domain 
    --> domain_factory 

Answer 2

메모리에서 Eric Evans의 책에는 객체 팩토리가 도메인 계층의 상당 부분을 차지하는 예제가 있습니다.

나를 위해, 당신의 공장을 이곳에 위치시키는 것이 합리적입니다.

Answer 3

DDD의 공장은 factory pattern의 인스턴스 일 뿐이므로 최대한 의미가있는 곳에 사용해야합니다. 고려해야 할 또 다른 원칙은 본질적으로 동작이 정보에 가장 가까운 클래스에 지정되어야한다고 명시하는 패턴입니다. 따라서 도메인 특정 규칙과 논리를 적용하려는 경우 도메인 계층에 팩토리를 배치하십시오. 결국 팩토리는 도메인 객체를 만듭니다. 그러나 다른 레이어에는 다른 유형의 팩토리가있을 수 있습니다.

Answer 4

하는 업체/공장은 다른 도메인 층 외부를 배치, 도메인 클래스와 기본 요소에 종속 도메인 층에 배치합니다.

Answer 5

나는 응용 프로그램 계층에서 팩토리를 선호합니다.

는 도메인 계층에 공장을 유지하는 경우는 매개 변수로 복잡한 유형 (C# 코드 예제) 필요로 할 때, 그들이 당신을 도움이되지 않습니다 : 또한

Application Layer: 

//this Factory resides in the Domain Layer and cannot reference anything else outside it 
Person person = PersonAggregateFactory.CreateDeepAndLargeAggregate(
      string name, string code, string streetName,... 
      and lots of other parameters...); 

//these ones reside in Application Layer, thus can be much more simple and readable: 
Person person = PersonAggregateFactory.CreateDeepAndLargeAggregate(CreatePersonCommand); 
Person person = PersonAggregateFactory.CreateDeepAndLargeAggregate(PersonDTO); 



Domain Layer: 

public class Person : Entity<Person> 
{ 
    public Address Address {get;private set;} 
    public Account Account {get;private set;} 
    public Contact Contact {get;private set;} 
    public string Name {get;private set;} 

    public Person(string name, Address address,Account account, Contact contact) 
    { 
     //some validations & assigning values... 
     this.Address = address; 
     //and so on... 

    } 

} 

public class Address:Entity<Address>{ 
    public string Code {get;private set;} 
    public string StreetName {get;private set;} 
    public int Number {get;private set;} 
    public string Complement {get;private set;} 
    public Address(string code, string streetName, int number, string complement?) 
    { 
     //some validations & assigning values... 
     code = code; 
    } 

} 

public class Account:Entity<Account>{ 
    public int Number {get;private set;} 

    public Account(int number) 
    { 
     //some validations & assigning values... 
     this.Number = number; 
    } 

} 

//yout get the idea: 
//public class Contact... 

을, 내부 유지 공장에 대한 의무가 없다 (Domain Driven Design Quickly)에서 도메인 계층 그러므로

는 자체 더 재를 갖지 않을 수 개별 객체에 복잡한 목적 및 응집체 인스턴스를 생성하는 책임을 이동 도메인 모델의 스폰서 쉽이지만 은 여전히 ​​ 도메인 디자인의 일부입니다. 모든 복잡한 어셈블리를 캡슐화하고 클라이언트가 구체화 된 인스턴스의 인스턴스를 참조 할 필요가없는 인터페이스를 제공하십시오. 전체를 하나의 단위로 만들어 불변량을 적용합니다.

팩토리를 사용하여 메모리에 영구 객체를로드하지 않기 때문에 응용 프로그램의 다른 레이어에서 액세스 할 필요가 없습니다. 다음 (Domain Driven Design Quickly에서) 이유는 다음과 같습니다

또 다른 관찰 공장은 처음부터 새로운 객체 를 만들 필요가, 또는 그들이 이전에 존재하는 객체를 재구성해야하지만, 아마도되어 데이터베이스에 지속 한 것입니다. 데이터베이스에있는 나머지 장소에서 엔티티를 다시 메모리에 가져 오려면 을 새로 만드는 것과 완전히 다른 프로세스가 필요합니다. 한 가지 분명한 차이점은 새 개체에는 새 ID가 필요하지 않습니다. 객체에는 이미 하나가 있습니다. 불변량의 위반은 다르게 취급됩니다. 새로운 개체가 처음부터 만들어지면 불변량 위반은 예외적으로 으로 끝납니다. 데이터베이스에서 다시 만든 개체로는이 작업을 수행 할 수 없습니다. 개체를 어떻게 든 복구해야하므로 기능을 수행 할 수 있습니다. 그렇지 않으면 데이터가 손실 될 수 있습니다.