"응용 프로그램 x에는 다중 계층 아키텍처의 오버 헤드를 정당화 할만큼 복잡한 도메인이 없습니다. 데이터 접근 방식에 중점을 둡니다. " 나는 어떤 특성이 특정 접근법을 강요 할 수있는 영역인지 궁금합니다. 즉, 데이터를 통해 양식과 같은 간단한 작업을 할 때 또는 여러 계층, 도메인, DTO 등으로 빌드해야하는 경우를 어떻게 알 수 있습니까?"데이터 오버플로"응용 프로그램, 즉 DDD 응용 프로그램을 인식하는 경우
두 옵션 모두 소프트웨어 소프트웨어를 작성하는 데 도움이됩니다. (이들은 보통의 용의자입니다 - 당신이 직접 또는 간접적으로 지불하는 프레임 워크)
중간에 어딘가에있는 패턴과 관행을 가질 수 있다고 생각합니다. 소프트웨어를 작성하지만 대부분의 경우에는 이미 익숙한 것을 적합합니다. (핵심 단어는 "패턴"과 강력하게 결합 된 관계라고 생각합니다.)
좋은 예는 새로 인기있는 MVC 개념 프레임 워크 (및 그 친척)입니다. 이것들은 꽤 일반적으로 취급 될 수 있습니다; 플랫폼, 컨텍스트 및/또는 개인 취향에 따라 도구를 지불할지 여부는 선택할 수 있습니다. 그러나 MVC 등이 당황하거나 압도 당할 상황이별로 없다고 생각합니다. (그러나이 질문에서 제시된 두 가지 옵션 중 하나는 결정적으로 더 적합 할 것입니다.)
적어도 나는 정말로 열심히 노력합니다. 중간 경로를 찾으십시오. 그렇게하지 않으면 짧은 라이프 사이클 패턴과 도구 및 확장 성 문제가 발생할 수 있습니다 (질문에서 직접 언급 함).
이것은 결코 결정적인 것은 아니지만 데이터에 대한 양식은 주로 비즈니스 규칙에서 가볍고 가벼운 도메인을 의미한다고합니다. 즉, 화면에서 일정한 데이터 구조로 데이터를 입력하는 경우, DDD 아키텍처가 그다지 중요하지 않다고 생각합니다. 그러나 도메인이 여러 집계로 구성되어 있거나 매우 비즈니스 규칙이 무거운 경우 DDD에 대해 고려해야합니다.
물론 우리 세상의 모든 것들과 마찬가지로 중간에 많은 회색 영역이 있으며 최선의 판단은 결정을 내리는 데 필요한 모든 것입니다.
이 질문은 DDD message board
에 질문 할 수 있습니다.