29

저는 소프트웨어 개발에있어서 새로운면이 있습니다. 개인적으로 계층화 된 아키텍처는 객체 지향 접근 방식에서 소프트웨어 개발 과정에서 발생하는 복잡성을 줄이는 것은 물론, 코드를 체계적으로 유지하는 데 좋은 방법이라고 생각합니다. 이제는 DDD (Domain Driven Design)에 대해 소개 할 몇 가지 문제에 직면 해 있습니다. Ofcourse, 초급 수준의 것들.
여기에 -
예를 들어, "사람"관련 데이터를 데이터베이스에 저장하고 사람 세부 정보를 wpf 데이터 그리드에 표시하는 응용 프로그램을 작성하려고합니다 (DDD는 분명히 이러한 규모의 응용 프로그램 용이 아니지만 나 같은 아마추어에게는 단순한 것들). , DDD에 대한 이해가 아키텍처 (그것의 간단한 버전) 다음과 같이 (내가있어 경우에 저를 수정하시기 바랍니다해야 말한다 지금DDD : 레이어를 구성하는 방법은 무엇입니까?

public class Person 
{ 
    public Person(dataType paramA, dataType paramB) 
    { 
     _fieldA = paramA; 
     _fieldB = paramB; 
    } 

    private dataType _fieldA; 
    public dataType PropertyA 
    { 
     //encapsulates _fieldA  
    } 

    private dataType _fieldB; 
    public dataType PropertyB 
    {   
     //encapsulates _fieldB  
    } 

    public dataType PropertyX 
    {   
     //some code based on private fields  
    } 

    public dataType PropertyY 
    {   
     //some code based on private fields  
    } 

    private dataType MethodPQR(dataType param) 
    {   
     //some code  
    } 

    public dataType MethodUVW(dataType paramOne, dataType paramTwo) 
    {   
     //some code  
    } 
} 

- 그래서, 내가 뭔가처럼 도메인 클래스 "사람을"설계) 잘못된 -
enter image description here
참고 :

  1. 나는 데이터 그리드 단지 즉시 변경의 종류를 반영하기 위해, 일부 ObservableCollection에 바인딩되고 싶어요.

  2. 는 WPF 응용 프로그램이다 그러나 반드시 MVVM 패턴으로 나는 의도적으로 (자체 뒤에 코드가 응용 프로그램 계층을 나타내는 경우에 나는 아무 생각이 없음) 그래서 뒤에

를 코드를 사용하고자하는 내 질문은 -

  1. 어떤 종류의 코드가 응용 프로그램 계층에 속해야합니까?

  2. 내 생각에, 필자는 내 도메인 개체 (Person)의 ObservableColletion을 DataGrid의 itmsSource로 바인딩해서는 안됩니다. 어떤 유형의 객체를 도메인 객체에서 추출해야합니까?

  3. 프리젠 테이션 레이어 개체와 도메인 레이어 개체 간의 연결을 유지하려면 “never instantiate domain objects directly in presentation layer”과 같은 규칙이있을 수 있습니다. 그렇다면 비 직접적인 접근 방식은 무엇입니까?

  4. 코드 숨김이 응용 프로그램 계층과 대화하는 경우 응용 프로그램 계층이 저장소와 대화해야합니까? 하지만 어떤 종류의 도메인 액세스가 필요한 경우 이 아니고 데이터 액세스와 관련이 있습니다 (이 응용 프로그램에는 없지만 발생할 수 있음). 도메인 계층에서 응용 프로그램 계층과 통신해야하는 사람은 누구입니까?

나는 모든 나의 질문과 문제점이 매우 아마추어 수준이라는 것을 알고있다. 그러나 그들은 실제로 질문과 문제입니다. 누군가에게 시간이 있다면, 어떤 반응이라도 인정 될 것입니다.

EDIT : 데이터 저장소에 도메인 모델 참조가 있어야하는지 확실하지 않습니다.

답변

32

더 많은 "클래식"DDD로 말하자면 예 도메인 개체는 일반적으로 도메인 외부에서는 허용되지 않습니다. 그러나 도메인 개체가 프레젠테이션 계층에서 사용되지 않는 것은 절대 규칙은 아닙니다. 예를 들어 Naked Objects는 도메인 객체가 직접 사용되는 사고 방식을 나타냅니다.나 자신은 주로 도메인 객체가 직접적으로 사용되지 않는 철학을 고수한다. 그래서 나는 그들이 제안한 모든 관행에 익숙하지 않다. 나는 개인적으로 도메인 객체에 대한 바인딩이 직접적으로 좋지 않을 것이라고 생각할 것이다. 그러나 명심하자. 모든 사람들이 이것을 요구 사항으로 간주하지는 않습니다.

도메인 외부의 도메인 개체를 허용하지 않으면 일반적으로 도메인 동작이없는 단순 속성 전용 클래스 인 DTO 또는 데이터 전송 개체를 사용합니다. DTO는 종종 도메인 모델 구조를 정확하게 미러링하지만 반드시 그렇게 할 필요는 없습니다.

비즈니스 로직이 도메인 모델에 구현되어 있다고 가정하면 응용 프로그램 계층에있는 많은 부분이 일반적으로 클라이언트 응용 프로그램간에 데이터를 가져 오는 다양한 서비스를 조정하는 것과 관련됩니다. 많은 사람들이 SOA를 위해 최소한의 웹 서비스를 사용합니다. 이들은 저장소를 호출하지만 어셈블러와 같은 다른 구성 요소가 저장소 호출에서 반환 된 도메인 객체를 가져 와서 속성 값을 DTO로 복사 한 다음 직렬화하여 호출자에게 반환합니다. 호출자는 종종 발표자 또는 컨트롤러이지만 MVC 또는 MVP를 사용하지 않는 경우 호출자는 여전히 프리젠 테이션 계층에있게됩니다. 역방향 이동은 더욱 복잡합니다. UI는 업데이트를 나타내는 DTO 또는 추가 할 새 객체를 나타내는 DTO를 되돌려 보낼 수 있습니다. 이러한 앞뒤 활동을 중재하는 것이 주로 응용 프로그램 계층의 목적입니다.

도메인 계층의 "비 데이터 액세스"에 관해서는 몇 가지 전형적인 예가 있습니다. 대부분의 사람들은 일반적으로 도메인 서비스라고 생각할 수있는 "X"구성 요소를 참조합니다. 도메인 서비스는 응용 프로그램 서비스와 도메인 모델의 근접성 및 실제 비즈니스 논리의 존재 여부에 따라 다릅니다.

예를 들어, 응용 프로그램에 일종의 주문 배치가 포함되는 경우 실제로 주문 배치와 주문 이행이라는 두 가지 문제가 있습니다. 응용 프로그램 서비스는 주문 배치를 UI에 공식화하는 데 필요한 데이터의 전송을 조정 한 다음 사용자가 배치 할 주문을 반환합니다. 하지만 이는 데이터 전송을 중재하는 것 뿐이며 애플리케이션 서비스가 종료됩니다. 그런 다음 비즈니스 규칙을 적용하고 해당 주문을 실제로 수행하는 데 필요한 추가 도메인 개체를 구성하려면 도메인 서비스가 필요할 수 있습니다.

일반적으로 많은 시나리오에 적용 할 수있는 유용한 개념 또는 은유로 나타납니다. 응용 프로그램 서비스는 submission 요청과 관련하여 일종의 요청을 용이하게합니다. 한편 도메인 서비스는 실제 요청을 용이하게합니다 이행.

내가 만났거나 쉽게 상상할 수있는 데이터 지향 이외의 유일한 "액세스"모드는 프로세스 지향적 인 기능입니다. 이것은 모든 어플리케이션에서 발생하지는 않지만 특정 분야에서 만연합니다. 예를 들어 일하는 건강 관리 분야에서 임상 데이터뿐 아니라 임상 프로세스를 관리하는 중요한 요소를 포함하는 애플리케이션을 원할 수 있습니다. 나는이 프로세스 강조를 내 도메인 모델의 일부로 삼아서 대신 다른 도구를 사용함으로써이 문제를 해결합니다.

OOP 기술은 실제 프로세스 자체에 적합하지 않으므로 프로세스에 데이터를 제공하고 프로세스에서 데이터를 캡처하는 데 유용합니다. 객체 지향은 결국 역시 주로 명사 지향적이다. 실시간 프로세스 관리를 위해서는 "명사 지향 프로그래밍"이상의 "동사 지향 프로그래밍"이 필요합니다. 워크 플로 도구는 데이터 집약적이고 프로세스 집약적 인 응용 프로그램을위한 도메인 기반 모델을 보완 할 수있는 "동사 지향"도구입니다. C# DDD 모델과 Workflow Foundation 모델을 모두 포함하는 많은 작업을 수행하지만이 작업은 특정 유형의 응용 프로그램에만 필요합니다. 많은 일반적인 비즈니스 앱에는 도메인 모델과 서비스 만 필요합니다.

마지막으로 DDD의 가장 중요한 측면은 기술이나 아키텍처가 아닙니다. 그것의 진정한 핵심은 유비쿼터스 언어와 중요한 지식에 대한 지식을 추출하기위한 도메인 전문가들과의 직접적인 상호 작용과 상호 작용합니다. (내 의견으로는 DDD를한다고 주장하는 대부분의 회사는 비즈니스와 개발이 직접 상호 작용할 수 없기 때문에 거부하지는 않지만 또 다른 주제입니다 ...) 도메인 지식의 추출 및 통합 기술은 DDD를 기존의 OOP와 실제로 구분하고 DDD의 실제 가치가 발생하는 곳입니다.

EDIT

은 아득히 저장소 사용 간다 다이어그램 맞습니다. 일반적으로 응용 프로그램 계층은 항상 도메인 개체의 저장소를 통과합니다. 무엇보다 먼저 응용 프로그램에 데이터를 가져와야하며 대부분의 응용 프로그램에는 일정 수준의 쿼리 기능이 필요합니다.

일반적으로 도메인 계층 OTOH는 이 아니고은 리포지토리와 상호 작용합니다. 일반적으로 도메인 모델을 특정 기술로부터 분리하여 분리해야합니다. 즉 "순수 도메인 지식"을 나타내야합니다. 지속성은 특정 종류의 특정 기술과 밀접하게 결합되어 있으므로 일반적으로 사람들은 도메인 모델을 지속성 구현에서 자유롭게 만들려고 노력합니다. 리포지토리가 있지만 일반적으로 도메인 모델에서 리포지토리 메서드를 호출하고 싶지는 않습니다.

도메인 모델 자체 내에서 개체는 새 개체 (직접 인스턴스화되거나 공장을 통해 인스턴스화 될 수 있음) 또는 통과 연결을 통해 도달 할 수 있습니다. 때로는 새 객체를 만들 때 필요한 모든 것을 생성자에 전달하는 것이 비현실적이므로 도메인 모델 자체에서 일종의 데이터 액세스가 필요할 수도 있습니다. 일반적으로 사람들은 인터페이스를 통해 데이터 서비스를 전달하므로 도메인 모델에 데이터 액세스가 제공되지만 데이터 계층 구현과 분리됩니다. 그러나 대부분의 경우 도메인 객체는 이미 인스턴스화 된 다른 도메인 객체와 상호 작용하고 상호 작용합니다.

+0

@Sisyphus : 지금 당장은 깨끗하고 자세한 설명과 나에게 계몽을위한 시간을 할애하십시오. 그러나 더 많은 질문이 당신에게 올 것입니다. – atiyar

+0

@Syyphus : 다시 한번 감사드립니다. 귀하의 제안은 훌륭했으며 응용 프로그램 서비스와 도메인 서비스의 차이점에 대한 예가 매우 유용했습니다. 한 번만 더 질문합니다. 응용 프로그램 계층이 리포지토리에 직접 액세스해야합니까? 아니면 항상 도메인 계층을 통과해야합니까? 내 말은 거의 모든 요청 ** 이행 **은 요청 ** 제출 **에 대한 도메인 제한 (검증 일 수 있음) 검사를 수행한다는 것입니다. 맞습니까? 그런 다음 응용 프로그램 계층이 모든 요청을 도메인 계층에 제출하지 않아야하며 도메인 계층 만 저장소에 액세스 할 수 있습니까? – atiyar

+1

의견이 제한되어 있으므로 내 답변에 추가했습니다. EDIT 섹션을 참조하십시오. – Sisyphus