엔티티 및 값 개체에 대한 네임 스페이스를 만들어야합니까?

Question

DDD 원칙을 사용하여 응용 프로그램을 작성하고 있습니다. 이제 응용 프로그램의 핵심 인 네임 스페이스 구조에 대해 생각하고 있습니다. 아래의 아이디어를 참조하십시오 :

Company.Application.Core.Entities 
Company.Application.Core.ValueObjects 

그러나 GitHb에서는이 규칙을 따르는 응용 프로그램 예제를 찾을 수 없습니다. 이 명명 규칙을 따르지 않는 특별한 이유가 있습니까? 엔티티는 Company.Application.Core.Entities.Entity 즉 가치 객체의 기본 클래스는 Company.Application.Core.ValueObjects.ValueObject

대안 옵션은 모든 값 객체 및 엔티티 넣어하는 것, 즉 대한

는 또한 기본 클래스가 있습니다 별도의 네임 스페이스를 사용 Company.Application.Core

Answer 1

귀하의 접근 방식은 효과가 있지만 이러한 구성은 귀하 도메인의 내재적 인 기능이 아니라 DDD 빌딩 블록에 초점을 맞춘 귀하의 코드에 관한 이야기입니다. DDD에서 우리는 도메인에 관한 중요한 것을 보여주고 싶습니다. 기술 문제는 더 이상 중요한 관심사가 아닙니다.

내가 만들고 다음 네임 스페이스를 제안 : 모든 응용 프로그램 범위 빌딩 블록을 유지할 수 있습니다 여기에

YourCompany.YourApplicationName.YourParticularBoundedContextName.Application 

즉 응용 프로그램 서비스에 매개 변수를 전송하고 데이터를 반환하는 데 사용되는 응용 프로그램 서비스와 DTO의.

YourCompany.YourApplicationName.YourParticularBoundedContextName.Domain 

이것은 도메인 범위 작성 블록의 하위 네임 스페이스를 만들 이름 공간입니다.

YourCompany.YourApplicationName.YourParticularBoundedContextName.Domain.AggregateName 

각각 집계는 C#으로이 경우 모르겠어요 등이 집계 루트 클래스, 엔티티이며, VO로이 집계, 저장소 인터페이스에서 내부적으로 사용하는 자신의 네임 스페이스, 골재 공장이 필요한 경우 이 가능하지만 Java에서는 Aggregate에 별도의 패키지 (네임 스페이스)를 갖는 또 다른 이점이 있습니다. Aggregate Root 클래스를 공용으로 만들 수 있으며 내부적으로 패키지 범위로 사용되는 다른 모든 Entities 및 VO를 만들 수 있으므로 패키지 외부에서 볼 수 없습니다 (네임 스페이스). 컴파일러 : 여기

YourCompany.YourApplicationName.YourParticularBoundedContextName.Infrastructure 

이 저장소 '구현을위한 장소 (집계 대응 subnamespace 각)

입니다 : 보호자가 있기 때문에이 방법을 사용하면, 아무도 깰 수 없다는 당신의 집계에 대한 공개 API를 구축

기본 클래스에서 유지 될 수있다 :

YourCompany.YourApplicationName.Domain 

및 다른 응용 프로그램에서 다시 시도 할 수 있습니다로도 별도의 프로젝트에 보관.

이점은 무엇입니까? 코드로 작업 할 때 기술 측면보다는 기능 및 도메인에 주력합니다. "이 프로세스 흐름이 어떻게 생겼는지"와 같은 문제에 대처해야 할 때가 많습니다. "모든 Entities 및 VO를 한꺼번에보고 싶습니다."라는 코드 구조를 지원해야합니다.엔티티 (실제로 파트를 집계)와 VO (집계 파트)를 별도의 네임 스페이스로 분리하면 무엇으로 작업하는지 정보가 손실됩니다. 큰 진흙 구슬로 간단하게 끝낼 수 있습니다. 재사용해서는 안되는 것을 재사용 할 것이기 때문입니다.

다음을보십시오. https://github.com/BottegaIT/ddd-leaven-v2 이 방법으로 패키징 된 Java의 샘플 프로젝트입니다. 어쩌면 그것은 당신을 도울 것입니다.

또 다른 예로는 Daugh에 관한 Vaughn Vernon의 책 샘플 인 https://github.com/VaughnVernon/IDDD_Samples 이 있습니다. 내가 도메인 층에 대해 이야기하고 http://www.codingthearchitecture.com/2015/03/08/package_by_component_and_architecturally_aligned_testing.html

Answer 2

당신의 .Entities 및 .ValueObjects이 특히 일반적인 선택이 아니더라도 엔터티 형식 (데이터베이스 테이블에 매핑되는 등) 및 DTO 형식 (응용 프로그램의 클라이언트와 서버 계층간에 데이터를 전달하는 데 사용됨)은 꽤 표준적인 방법입니다. 나는 당신이 그것들을 일관성있게 사용하는 한 너무 많이 걱정할 필요가 없다고 생각합니다.