DDD-Lite는 의존성 주입을위한 패턴 언어입니까?

나는 7 시 20 분에 DDD-Lite라고 불리는 것을 언급하면서 DDD 프로젝트가 실패한 7 가지 이유에 대해 Greg Young의 이야기를 우연히 발견 했습니다.

요약하면, 그는 기본적으로 DDD를 DDD와 관련된 다른 작업을 수행하지 않고 패턴 언어 (엔터티, 리포지토리, 가치 객체, 서비스 등)로 사용한다고 말합니다. 그는 .Net의 도메인 모델 중 60 % 이상이 DDD-Lite라고 가정합니다. 그는 DDD-Lite가 기본적으로 의존성 주입과 관련된 언어를 작성한다고 생각합니다. 실제로 할 필요는 없습니다. 그는 DDD를 완전히 수행하거나 더 간단한 것을 수행한다고 말합니다. 그렇지 않으면 그는 좋은 추상화를 구축하기 위해이 작업을 모두 수행하고 있지만 실제 이점은 없다고 주장합니다.

나는 내가 원하는만큼 DDD에 대해 잘 모른다는 것을 인정해야하며, 아직 그것을 사용하려하지는 않았다. 나는 또한 Eric Evan의 책을 읽지 않았습니다. 나는 Dependency Injection에 훨씬 더 관심이 있으며이 주제에 관한 많은 책과 블로그는 Eric Evans의 DDD 서적에서 사용 된 용어와 참조 개념을 사용합니다. 이것은 내가 DDD 개념에 노출 된 곳이다. 내가 읽은 책은 다음과 같습니다.

• .NET에서 의존성 주입
• Microsoft .Net : 엔터프라이즈를위한 애플리케이션 설계
• .NET의 브라운 필드 애플리케이션 개발

의존성 주입을 원한다면 "DDD-Lite"를 수행하는 것보다 간단한 대안은 무엇입니까? DDD의 개념을 "DDD-Lite"방식으로 사용하는지 여부에 관계없이 훌륭한 추상화를 작성하는 것이 매우 유용합니다. (마크 시만의 블로그 게시물을 참조 : 인터페이스가 추상적 없습니다 , 그리고 더 나은 추상화 향해 ). Dependency Injection을 수행하는 모든 사람이 본격적인 DDD를 수행하거나 수행해야한다고 생각하는 데 어려움을 겪고 있습니다. DDD-Lite에 대한 Greg Young의 주장을 어떻게 든 내가 잘못 이해 했습니까?

의존성 주입과 DDD는 두 가지 분리 된 개념입니다. 의존성 주입을 수행하면 DDD를 수행 할 필요가 없으며 DDD는 의존성 주입을 요구하지 않습니다.

많은 DDD 프로젝트는 패턴을 선택하지만 DDD 뒤의 프로세스를 무시하기 때문에 실패합니다. 비즈니스 규칙을 추출하는 데 시간이 걸리지 않습니다. 그들은 도메인 모델과 신중한 추상화에 집중하지 않습니다. 그들은 유비쿼터스 언어를 확립하지 않습니다.

한마디로 : 그것은 오해 인 것 같아

Greg는 전체 DDD 방식 대신 Domain-Driven Design 패턴의 하위 집합 인 경우 간단한 응용 프로그램을 언급합니다. DDD-Lite라는 용어는 암묵적으로 DDD 초보자들에게 인기가 있었지만 http://www.infoq.com/minibooks/domain-driven-design-quickly 책을 의미 하지만 로컬 모델링 디자인 패턴.

Dependency Injection은 좋은 것으로 간주되지만 DDD와 DI 사이에는 강한 상관 관계가 없습니다.