이 모든 서비스를 통해 빈혈을 예방하려면 어떻게해야합니까?

비즈니스 로직 위임과 캡슐화 사이의 경계를 어디에서 그릴까요? 우리가 더 많이 위임할수록 더 빈혈 이되는 것 같습니다 . 그러나 대표단은 또한 재사용과 DRY 교장을 장려합니다. 그렇다면 위임하는 것이 무엇이고 도메인 모델에 무엇이 남아 있어야합니까?

다음 우려 사항을 예로 들어보십시오.

승인 . 도메인 개체가 액세스 제어 규칙 (예 : CanEdit 속성)을 유지 관리해야합니까, 아니면 액세스 관리를 담당하는 다른 구성 요소 / 서비스 (예 : IAuthorizationService.CanEdit (object))에게 위임되어야합니까? 아니면 둘의 조합이어야합니까? 아마도 도메인 개체에 실제 작업을 수행하기 위해 내부 IAuthorizationService에 위임하는 CanEdit 속성이 있습니까?

검증 . 위와 동일한 설명은 유효성 검사와 관련이 있습니다. 누가 규칙을 유지하고 누가 평가할 책임이 있습니까? 한편으로 객체의 상태는 해당 객체에 속해야하며 유효성은 상태이지만 모든 도메인 객체의 규칙을 평가하는 데 사용되는 코드를 다시 작성하고 싶지는 않습니다. 우리는 수 ,이 경우 상속을 사용 ...

객체 생성 . 팩토리 클래스 대 팩토리 메소드 대 인스턴스 새로 만들기 별도의 팩토리 클래스를 사용하면 생성 로직을 분리하고 캡슐화 할 수 있지만 객체의 상태를 팩토리에 공개하지 않아도됩니다. 팩토리에서 사용하는 내부 생성자를 노출하여 도메인 계층이 별도의 어셈블리에있는 경우 관리 할 수 ​​있지만 여러 생성 패턴이있는 경우 문제가됩니다. 그리고 모든 팩토리가 올바른 생성자를 호출하는 것이라면 팩토리를 갖는 것이 무엇입니까?

클래스의 팩토리 메소드는 객체의 내부 상태를 여는 데 따른 문제를 제거하지만 정적이기 때문에 별도의 팩토리 클래스를 사용하는 것처럼 팩토리 인터페이스를 주입하여 종속성을 깰 수 없습니다.

끈기 . 도메인 오브젝트가 CanEdit을 노출시키면서 권한 확인을 다른 당사자 (IAuthorizationService)에게 수행 할 책임을 위임하면서 왜 도메인 오브젝트에 동일한 방법을 수행하는 Save 메소드가 없는가? 이를 통해 객체의 내부 상태를 평가하여 캡슐화를 중단하지 않고 작업을 수행 할 수 있는지 확인할 수 있습니다. 물론 리포지토리 인스턴스를 도메인 객체에 주입해야합니다. 도메인 객체에 약간의 냄새가납니다. 대신 도메인 이벤트를 발생시키고 처리기가 지속성 작업을 수행하도록 허용합니까?

내가 어디로 가는지 보아?

Rockford Lhotka는 CSLA 프레임 워크에 대한 충전 클래스 경로를 사용해야하는 이유에 대해 큰 토론을하고 있으며 해당 프레임 워크에 대해 약간의 역사가 있으며 도메인 오브젝트를 병렬화하는 비즈니스 오브젝트에 대한 그의 아이디어를 여러 가지 방법으로 볼 수 있습니다. 그러나 좋은 DDD 이념에 더 충실하려고 노력할 때 협업이 과도해질 때 궁금합니다.

집계 루트에 대해 IAuthorizationService, IValidator, IFactory 및 IRepository로 끝나는 경우 남은 것은 무엇입니까? 클래스가 비 핵심 도메인 객체로 간주 될 수있을 정도로 객체의 상태를 초안에서 게시 됨으로 변경하는 Publish 메소드가 있습니까?

당신의 생각?

혼란의 대부분은 도메인 모델에 존재해서는 안되는 기능에 관한 것 같습니다.

• 지속성 은 도메인 모델에 있어서는 안됩니다. 절대로. 그렇기 때문에 IRepository모델의 일부가 모델의 다른 부분을 검색하는 것과 같은 작업을 수행해야하고 종속성 주입 또는 유사한 기술을 사용하여 구현을 연결해야하는 경우 와 같은 추상 유형에 의존하는 이유가 있습니다 . 그래서 기록에서 그것을 쳤다.

• 권한 부여 하지 않습니다 일반적으로 실제로 보안 소프트웨어를 작성하는 경우 예를 들어 도메인의 일부가 아닌, 도메인 모델의 일부. 애플리케이션에서 무엇을 수행 할 수 있는지에 대한 메커니즘은 일반적으로 비즈니스 / 도메인 계층의 "가장자리"에서 처리됩니다. UI 및 통합 부분에서 실제로 대화 할 수있는 공용 부분-MVC의 컨트롤러, 서비스 또는 SOA의 메시징 시스템 자체 ... 그림을 얻습니다.

• 팩토리 (여기서 추상 팩토리를 의미한다고 가정)는 도메인 모델에있는 것이 나쁘지 는 않지만 거의 항상 불필요합니다. 일반적으로 객체 생성의 내부 메커니즘이 변경 될 수있는 경우에만 공장이 있습니다. 그러나 하나의 도메인 모델 구현 만 가지고 있습니다. 즉, 항상 동일한 생성자와 다른 초기화 코드를 호출하는 하나의 팩토리 만 존재합니다.

  생성자 매개 변수의 공통 조합 등을 캡슐화하는 클래스 등 원하는 경우 "편의성"팩토리를 가질 수 있습니다. 그러나 솔직히 말해서 일반적으로 도메인 모델에 많은 팩토리가 있으면 라인을 낭비하게됩니다. 코드

따라서 일단 모든 것을 터프하면 유효성 검사 만 남습니다. 그것은 까다로운 유일한 사람입니다.

유효성 검사 는 도메인 모델의 일부이지만 응용 프로그램의 다른 모든 구성 요소의 일부이기도합니다. UI와 데이터베이스는 비슷하지만 다른 개념 모델을 기반으로 유사한 유사하지만 다른 유효성 검사 규칙을 갖습니다. 객체에 Validate메소드 가 필요한지 여부는 실제로 지정되어 있지 않지만 실제로는 메소드를 검증 자 클래스에 위임합니다 (인터페이스가 아니라 도메인 모델에서는 유효성 검사가 추상적 이지 않습니다 ).

유효성 검사기는 여전히 기술적으로 모델의 일부입니다. 데이터 또는 상태를 포함하지 않으므로 집계 루트에 연결할 필요가 없습니다. 도메인 모델은 일반적으로 어셈블리 또는 어셈블리 모음으로 물리적으로 변환하는 개념적 것입니다. 위임 코드가 개체 모델과 매우 가까운 곳에있는 경우 "무기"문제를 강조하지 마십시오. 여전히 셉니다.

이 모든 것이 실제로 내려 오는 것은 DDD를 수행하려면 도메인 이 무엇인지 이해해야한다는 것 입니다 . 지속성 및 권한 부여와 같은 것에 대해 여전히 이야기하고 있다면 잘못된 길을 가고 있습니다. 도메인은 시스템의 실행 상태 (물리적 및 개념적 객체 및 속성)를 나타냅니다. 개체 및 관계 자체와 직접 관련이없는 것은 도메인 모델 기간에 속하지 않습니다.

경험상 어떤 것이 도메인 모델에 속하는지 여부를 고려할 때 다음과 같은 질문을하십시오.

"순전히 기술적 이유로이 기능을 변경할 수 있습니까?" 다시 말해, 실제 비즈니스 나 도메인이 눈에 띄게 변경 되었기 때문이 아닌가?

대답이 "예"이면 도메인 모델에 속하지 않습니다. 도메인의 일부가 아닙니다.

언젠가는 지속성 및 권한 부여 인프라를 변경할 가능성이 매우 높습니다. 따라서 도메인의 일부가 아니며 응용 프로그램의 일부입니다. 이것은 정렬 및 검색과 같은 알고리즘에도 적용됩니다. 도메인은 검색 방법이 아니라 추상적 검색 개념에만 관심이 있기 때문에 이진 검색 코드 구현을 도메인 모델에 적용해서는 안됩니다.

중요하지 않은 모든 것들을 제거 한 후에 도메인 모델이 실제로 빈혈 이라는 것을 알게되면 DDD가 단순히 프로젝트의 잘못된 패러다임이라는 좋은 지표가 될 것입니다.

일부 도메인은 정말로 있습니다 빈혈. 소셜 북마크 앱에는 실제로 말하는 "도메인"이 많지 않습니다. 모든 객체는 기본적으로 기능이없는 데이터 일뿐입니다. 반면 영업 및 CRM 시스템은 상당히 무거운 도메인을 가지고 있습니다. Rate엔터티를 로드 할 때 주문 수량에 적용하고 볼륨 할인 및 프로모션 코드 및 모든 재미있는 것들을 파악하도록하는 등 실제로 해당 비율로 물건 을 처리 할 수 ​​있다는 합리적인 기대가 있습니다 .

단지 데이터를 보유 도메인 객체는 일반적으로 않는 당신이 빈혈 도메인 모델을 가지고 있지만, 그것은하지 않는 것을 의미 반드시 그냥 도메인 자체가 빈혈 것을 의미 할 수 있습니다 당신은을 사용하는 것을 - 당신은 나쁜 디자인을 만든 것을 의미 다른 방법론.

권한 부여. 도메인 개체가 액세스 제어 규칙을 유지 관리해야하는 경우

아닙니다. 승인은 그 자체의 관심사입니다. 권한 부족으로 인해 유효하지 않은 명령은 가능한 빨리 도메인 전에 거부해야합니다. 즉 , UI를 구축하기 위해 잠재적 인 명령의 권한 부여를 확인하려는 경우가 종종 있습니다. 사용자에게 편집 옵션을 보여줍니다).

권한 부여가 도메인 모델과 별도로 구성 요소 화되어 있으면 계층 간 (UI 및 서비스 또는 명령 핸들러에서 추가) 권한 부여 전략을보다 쉽게 ​​공유 할 수 있습니다.

발생할 수있는 까다로운 부분 중 하나는 상황 별 권한 부여입니다. 여기서 사용자 역할뿐 아니라 비즈니스 데이터 / 규칙에 따라 명령이 허용되거나 허용되지 않을 수 있습니다.

확인, 검증. 위와 동일한 설명은 유효성 검사와 관련이 있습니다.

또한 도메인이 아니라고 대답합니다 (주로). 유효성 검사는 다른 컨텍스트에서 발생하며 유효성 검사 규칙은 종종 컨텍스트마다 다릅니다. 집계에 의해 캡슐화 된 데이터를 고려할 때 단순하고 절대적인 타당성 또는 타당성이 거의 없습니다.

또한 권한 부여와 마찬가지로 UI, 서비스 또는 명령 처리기 등에서 계층 간 유효성 검사 논리를 사용합니다. 다시 말하지만 별도의 구성 요소 인 경우 유효성 검사와 함께 DRY를 사용하는 것이 더 쉽습니다. 실질적인 관점에서, 검증 (특히 프레임 워크를 사용할 때)은 달리 캡슐화해야하는 데이터를 노출해야하며 종종 필드와 속성에 사용자 지정 특성을 첨부해야합니다. 나는 이것이 내 도메인 모델 이외의 다른 클래스에있는 것을 선호합니다.

유효성 검사 프레임 워크에 대한 요구 사항을 엔티티에 강제로 적용하는 것보다 몇 가지 유사한 클래스에서 일부 속성을 복제하려고합니다. 그것은 필연적으로 엔터티 클래스를 혼란스럽게 만듭니다.

객체 생성. 팩토리 클래스 대 팩토리 메소드 대 인스턴스 새로 만들기

간접 계층을 사용합니다. 최근 프로젝트에서 이것은 무언가를 생성하는 명령 + 핸들러입니다 CreateNewAccountCommand. 대안은 항상 팩토리를 사용하는 것일 수 있습니다 (하지만 나머지 엔티티 조작이 팩토리 클래스와 분리 된 서비스 클래스에 의해 노출되는 경우 어색 할 수 있음).

그러나 일반적으로 객체 생성을위한 디자인 선택으로 더 유연 해 지려고 노력합니다. new쉽고 친숙하지만 항상 충분하지는 않습니다. 여기서 판단을 사용하고 시스템의 다른 부분에서 필요에 따라 다른 전략을 사용할 수있게하는 것이 중요하다고 생각합니다.

고집. ... 도메인 객체에 Save 메소드가없는 이유

이것은 거의 좋은 생각이 아닙니다. 이를 지원할 수있는 공유 경험이 많이 있다고 생각합니다.

집계 루트에 대해 IAuthorizationService, IValidator, IFactory 및 IRepository로 끝나는 경우 남은 것은 무엇입니까? 클래스를 비애 논 도메인 개체로 간주하기에 충분히 개체 상태를 초안에서 게시 됨으로 변경하는 Publish 메서드가 있습니까 ???

아마도 응용 프로그램의이 부분에 도메인 모델이 올바른 선택이 아닐 수도 있습니다.

좋아, 여기에 간다. 나는 다음과 같이 말함으로써 이것을 전할 것이다 :

• 조기 최적화 (및 설계 포함)는 종종 문제를 일으킬 수 있습니다.

• IANMF (나는 Martin Fowler가 아닙니다);)

• 작은 비밀은 소규모 프로젝트 (아마도 중간 규모의 프로젝트)에서도 중요한 접근 방식의 일관성이라는 것입니다.

권한 부여

나를 위해 인증 및 권한 부여는 항상 교차 문제입니다. 저의 행복한 작은 Java 세계에서 그것은 스프링 보안 또는 Apache Shiro 프레임 워크에 위임됩니다.

유효성 검사 유효성 검사는 개체를 정의하는 것으로 볼 때 개체의 일부입니다.

예를 들어 Car 객체에는 4 개의 바퀴가 있습니다 (이상한 예외가 있지만 지금은 이상한 3 륜 자동차를 무시할 수 있습니다). 자동차는 (내 세계에서) 4를 갖지 않는 한 단순히 유효하지 않으므로 유효성 검사는 자동차 정의의 일부입니다. 그렇다고 도우미 유효성 검사 클래스를 가질 수 없다는 것을 의미하지는 않습니다.

행복한 Java 환경에서 Bean 유효성 검사 프레임 워크를 사용하고 대부분의 Bean 필드에서 간단한 주석을 사용합니다. 어떤 레이어에 있든 객체를 쉽게 검증 할 수 있습니다.

객체 생성

팩토리 클래스를주의해서 봅니다. 너무 자주 나는 xyxFactoryFactory수업 을 보았다 ;)

newDependency Injection이 보장되는 경우가 발생할 때까지 (필요에 따라 객체를 만드는 경향 이 있습니다.

나의 행복한 자바 세계에서 점점 기 이스이지만 점점 봄의 왕이 여기 있습니다.

고집

그래서 이것은 원형과 원형 교차로에서 진행되는 토론이며 나는 항상 그것에 대해 두 가지 생각을하고 있습니다.

어떤 사람들은 '순수한'방식으로 대상을 보면 지속성이 핵심 속성이 아니라 외부의 관심사 일 뿐이라고 말합니다.

다른 사람들은 도메인 객체가 암시 적으로 '지속 가능'인터페이스를 구현한다는 견해를 가지고 있습니다 (예, 여기서 스트레칭하고 있음을 알고 있습니다). 따라서, 다양한 가지고 괜찮아요 save, delete그들에 등 방법을. 이것은 실용적인 접근 방식으로 간주되며 많은 ORM 기술 (행복한 Java 세계의 JPA)은 이러한 방식으로 객체를 처리합니다.

교차 보안 문제로 개체의 save / update / delete 메서드를 호출하는 서비스에서 편집 / 삭제 / 추가 / 모든 권한이 올바르게 설정되어 있는지 확인합니다. 정말 편집증이라면 도메인 객체 자체에 대한 권한을 설정할 수도 있습니다.

HTH!

지미 닐슨 (Jimmy Nilsson)은 DDD에 관한 그의 책에서이 주제를 다룬다. 그는 빈혈 모델로 시작하여 이후 프로젝트에서 비 빈혈 모델로 가서 마침내 빈혈 모델에 정착했습니다. 그의 추론은 빈혈 모델이 다른 비즈니스 로직을 가진 여러 서비스에서 재사용 될 수 있다는 것이었다.

단점은 발견 가능성이 없다는 것입니다. 빈혈 모델에서 작동하는 데 사용할 수있는 방법은 다른 곳에 위치한 일련의 서비스에 분산되어 있습니다.

이 질문은 오래 전에 요청되었지만, Domain Driven Design으로 태그되었습니다. 나는 그 질문 자체가 전체 관행에 대한 근본적인 오해를 포함하고 있다고 생각하고 받아 들여진 대답을 포함한 대답은 근본적인 오해를 영속시킨다.

DDD 아키텍처에는 "도메인 모델"이 없습니다.

인증을 예로 들어 봅시다. 두 가지 다른 사용자가 시스템을 인증한다고 상상해보십시오. 한 사용자는 특정 엔티티를 변경할 권한이 있지만 다른 사용자는 변경할 수 없습니다. 왜 안돼?

나는 그들이 깨달은 것보다 더 많은 것을 혼동하기 때문에 간단하고 고안된 예가 싫어. 그러나 두 개의 서로 다른 도메인이 있다고 가정 해 봅시다. 첫 번째는 마케팅 대행사의 CMS 플랫폼입니다. 이 대행사의 고객은 모두 온라인으로 콘텐츠를 가지고 있으며 사본 작가와 그래픽 아티스트가 관리해야하는 많은 고객이 있습니다. 콘텐츠에는 블로그 게시물과 다양한 고객을위한 방문 페이지가 포함됩니다.

다른 도메인은 신발 회사의 재고 관리입니다. 이 시스템은 프랑스 제조업체, 미국 대륙의 유통 센터, 현지 시장의 소매점 및 소매점에서 신발을 구입 한 고객에 이르기까지 재고를 관리합니다.

승인 규칙이 두 회사 모두에 대해 동일하다고 생각하면 도메인 외부의 서비스에 적합한 후보가됩니다. 그러나 승인 규칙이 동일한 지 의심됩니다. 사용자의 기본 개념조차 다를 수 있습니다. 확실히 언어가 다를 것입니다. 마케팅 대행사는 아마도 포스트 작성자 및 자산 소유자와 같은 역할을하는 반면 신발 회사는 아마도 운송 직원이나 창고 관리자 또는 상점 관리자와 같은 역할을합니다.

이러한 개념에는 도메인에서 모델링해야하는 모든 종류의 권한 규칙이있을 수 있습니다. 그러나 이것이 동일한 앱 내에서도 모두 동일한 모델의 일부라는 의미는 아닙니다. 다른 Bounded Context가 있다는 것을 기억하십시오.

따라서 인증 맥락에서 비 핵심 도메인 모델을 클릭 한 광고에 따라 재고가 적은 매장으로 신발 배송을 라우팅하거나 적절한 방문 페이지로 라우팅하는 방문자의 맥락과 다른 것으로 간주 할 수 있습니다.

빈혈 도메인 모델을 사용하는 경우 코드 작성을 시작하기 전에 컨텍스트 매핑에 더 많은 시간을 투자하면됩니다.