답변:
글쎄, 우선, 당신이 참조하는 Wikipedia 기사가 매우 훌륭하다고 생각하지 않습니다. 주로 Domain Driven Design에 부수적 인 많은 것들을 참조하고 연습에 대해 누군가를 밝히지 않습니다.
그러나 Domain Driven Design을 마음에 새긴 사람 (보통 3D가 아닌 DDD가 가치가있는 것)으로, Eric의 첫 장만큼 많이 읽으면 항상 DDD의 기본 사항이 분명하다고 느꼈습니다. 에반스의 책. 그러나 그것은 일련의 패턴과 관행이므로, 그것이 무엇인지 그리고 어떤 세부 사항으로 들어 가지 않고 장점이 무엇인지에 대한 3 문장 요약을 제공하는 것은 쉽지 않습니다. 어떤 사람과 공감하는 세부 사항도 매우 다를 수 있습니다. 10 년 전에는 그 요점을 전혀 보지 못했을 것입니다.
DDD는 은색 총알이 아닙니다. 현명하게 수행되면 소프트웨어를 제작하는 데 장인과 같은 접근 방식을 취하고 개발 팀과 소프트웨어를 개발하는 비즈니스 사이의인지 적 마찰을 줄일 필요성을 인식하는 것입니다. 가장 중요한 방법 중 하나는 소프트웨어 팀과 비즈니스 팀이 사용하는 도메인 어휘가 가능한 한 밀접하게 일치하는 계층을 갖는 것입니다. 해결하려는 비즈니스 문제를 이해하기 위해이 계층을 반복적으로 빌드합니다. 비즈니스 로직이이 계층에서 현명하게 인코딩되고 엔터프라이즈 시스템이 인터페이스와 시스템 간의 상호 작용을 고려하여 엔터프라이즈 응용 프로그램이 갖는 모든 복잡한 종속성과 분리되면 실제 도메인 계층에서 사용되는 언어는 결국 매우 간결하고 명확하며 읽기 가능해집니다.
실제로 대부분의 엔터프라이즈 소프트웨어에서 본 모양을 고려할 때 실제로 DDD는 거의 불완전한 우려를 분리하고 소프트웨어 팀은 거의 테스트 할 수없는 우려를 가지고 있기 때문에 DDD는 은탄 처럼 들릴 수 있습니다. 표면적으로 사소한 코드 변경으로 인해 부작용이 어떤 영향을 줄지 모르지만, 적절하게 인수 분해 된 도메인 계층은 독립적으로 테스트 및 검증 할 수 있습니다. 그러나 실제로 DDD는 시스템이 고립되어있는 경우는 거의 없다는 것을 인정합니다. DDD에는 레거시 시스템 (부패 방지 계층, 경계 컨텍스트)에 대한 대처 패턴이 포함됩니다.
느슨한 결합의 규율을 포함하여 객체 지향 디자인을 연습하고 상당히 종교적으로 단위 테스트를 연습하고 코드를 무자비하게 리팩터링하고 시스템을 구축하는 동안 도메인 전문가와 협력하면 본질적으로 결과가 나타납니다. 기본적으로 도메인 기반 디자인을 옹호하는 사람들이 이야기하는 내용입니다.
에반스의 책에는 대부분 엔터프라이즈 소프트웨어 개발에 적용되는 몇 가지 특정 패턴이 있으며, 일부는 상당히 보편적 인 원칙이지만, 본질적으로 DDD는 시간이 지남에 따라 기술적 부채의 축적을 줄일 수있는 소프트웨어 개발에 대한 실용적인 접근 방식입니다. 서로 같은 언어를 사용하고 서로를 더 잘 이해한다는 이점으로 인해 더 효과적인 솔루션을 제공 할 수 있기 때문에 고객을 더 행복하게 만듭니다.
면책 조항 : 이 질문 이 중복으로 표시된 후에이 답변을 추가했습니다 . 동의하지 않지만 여기 있습니다. :-)
도메인 기반 디자인은 고 가치 / 복잡성 도메인에서 소프트웨어를 설계하는 것을 목표로합니다.
이것은 엔터프라이즈 소프트웨어 구축을위한 다른 접근 방식으로 바뀝니다. 너무 많은 학습이 필요하며, 가장 중요한 결과는 처음에 올바른 솔루션을 얻지 못할 것입니다.
또는 둘 다의 조합.
두 가지 방법 모두 훌륭한 소프트웨어 기반이 필요합니다 자주 다시 작성 합니다. 이것이이 책이 도메인 모델 패턴을 중심으로 주어진 패턴을 강조한 이유입니다. 2004 년에 가장 합리적인 조합이었습니다.
그러나 OOP와 전술 패턴은 가장 중요한 것은 아닙니다. 진화적인 방식으로 훌륭한 소프트웨어를 구축하려면 기술 숙달이 필요합니다. 그러나 그것은 레시피의 유일한 성분입니다. 다른 사람?