DDD는 시간 낭비입니까? [닫은

Question

인터넷 검색 "DDD는 어떤 종류의 응용 프로그램에 적합합니까?" 다음 답변을주었습니다.

아마도 모든 소프트웨어 응용 프로그램의 95%가 "DDD 사용에 좋지 않은"범주에 속할 것입니다. (보다 기사)

그래서 모든 소란은 무엇입니까?!?

내가 작업중인 응용 프로그램은 IS입니다 주로 데이터 중심이지만 여전히 일부 비즈니스 논리와 적용되는 규칙이 포함되어 있습니다. DDD 기술을 적용하는 것이 시간 낭비일까요? 보다 기존의 데이터 액세스 계층, POCO 모델 및 비즈니스 로직 계층을 사용하는 것이 좋습니다. 또는 다르게 언급하려면 DDD에 대한 건전한 대안은 무엇입니까?

Answer 1

DDD가 프로젝트에 유용하다고 생각하는 많은 개발자들은 자신의 직업이 무엇인지에 대한 트랩에 속합니다. 이것은 사실이 아닙니다. 개발자의 임무는 기능을 실현하는 것이므로 소프트웨어를 통해 문제를 해결할 수 있습니다. 이로 인해 코드 쓰기는 개발자가하는 일의 시작이 아니라는 결론이 발생하지만 끝은 코드가 실제로 작성되기 전에 전체 프로세스의 결과입니다.

DDD는 코드 작성에 관한 것이 아니며 훌륭한 소프트웨어를 얻는 턴키 10 단계 프로세스가 아닙니다. 코드가 작성되기 전에 전체 프로세스에 관한 것입니다. 문제가 무엇인지, 무엇에 관한 것인지, 누가 참여하는지에 대한 통찰력을 얻는 것입니다. 정보 스트림과 이러한 요소의 모습은 어떤 모습인가? 도메인 전문가와 개발자 간의 대화를 잘못 해석하지 않고 가능하게하는 언어 만들기. 이것은 '유비쿼터스 언어'에반스가 이야기합니다. 사실상 코드가 쓰여지기 전에 전체 프로세스를 구하기 전에 쓰여지지 않고 상황이 명확하고 간단합니다. (그게 목표입니다).

'DDD가 실제로 어떻게 작동합니까?'와 '누군가가 DDD로 코드를 작성하는 방법에 대한 예를 제시 할 수 있습니까?' 그리고 같은 것은 실제로 이러한 종류의 질문을하는 사람들이 코드 작성에 중점을두고 있지만 왜 다른 코드가 아닌 코드를 작성하는지 전혀 모른다는 사실에서 비롯됩니다. IOW : DDD가 기능으로 작성해야 할 내용과 그 이유를 발견하는 것임을 알게되면 상황이 제자리에 있습니다. 당신이 그 코드를 쓰는 방법, 그것은 당신에게 달려 있습니다. 그러나 말했듯이 : 그것은 당신이 이미 당신이 무엇을 써야하는지, 왜 그런지 알고 있기 때문에 더 이상 가장 큰 문제가 아닙니다.

Answer 2

때로는 5%가 다른 모든 95%보다 더 많은 돈을 벌 수 있습니다. 그래서 DDD가 존재하는 이유입니다.

특정 복잡한 대형 시스템을위한 것입니다.

Answer 3

미안하지만 DDD가 Frans Bouma가 말한 것처럼 생각하는 방법이라면 지속성 무지와 같은 것들을 권장하지 않을 것입니다. 이것은 다른 사람들을 다소 언더 클래스 개발자로 기각하고 있습니다.

DDD가 최소한 편견을 가진 PI는 건축 선택입니다. 더 이상 생각하는 방법이 아닙니다. 그것은 이미 당신에게 제공되는 것입니다. 대부분의 시간은 너무 모호한 경고가 "모든 것에 적합하지 않다".

그러나 Pi Way를 가기로 결정하는 것은 그 자체로 도전이되며, 이것에 대해 불안하다고 느끼면 누군가 이름 ( "코더")을 부를 수 없습니다.

MS Access-Like Interface를 모두 사용하여 ERP 패키지를 사용하여 총액이 달린 그리드, 자동 업데이트 열 및 100,000 레코드의 Pageless 스크롤. 분명히 DDD 접근법은이 앱을 찾는 방법을 생각하는 데 적합합니다. 그러나 몇 년 동안 나는 책이나 온라인에서 아무도 본 적이 없으며, PI가 어떻게 Pi가 이것을 다룰 수 있는지에 대한 증거를 뒷받침하는 증거를 뒷받침하지만 어디에나 있는 전달하고자하는 사람을위한 상황 상업용 등급 앱 및 사용자 경험.

이것에 대해 종교를 받고 싶지 않습니다. DDD와 DAL 지지자들은 지나치게 종교적인 경향이 있으며 한 번 물었지만 열린 마음을 가진 사람들을 몰아 낼 수 있습니다. 많은 사람들은 단지 실제 경험 (즉, 생각)에 직면하고 싶어하며, 고양이, 자동차, 기본 주문/주문 (즉, 코드가 열악한 코드)과 함께 제공되지 않기를 원합니다.

Answer 4

다음은 매우 유사한 질문입니다. 웹 계층이 DAL에 직접 액세스 할 수 있습니까?

모든 프로젝트에 DDD를 사용합니다. 소규모 응용 프로그램에서는 일부 개념이 적용되지 않지만 크기에 관계없이 모든 프로젝트에 많은 측면이 적용됩니다.

Answer 5

DDD는 잠시 동안 유지 될 소프트웨어에 관한 것입니다. 나에게 이것은 도메인으로 변화 할 아이디어를 표현해야한다는 것을 의미합니다. 간단한 앱은 짧은 배송 시간과 짧은 구현 시간에 적합 할 수 있습니다. 그러나 소프트웨어를 성장시켜야한다면 DDD 원칙이 엄청나게 도움이 될 것입니다. DDD는 어려울 수 있지만 일단 유비쿼터스 언어에 대한 아이디어와 분리 문제가 발생하면 상황이 쉬워지기 시작합니다.

Answer 6

기사를 조금 더 읽으면 다음을 볼 수 있습니다.

DDD가 적합한 애플리케이션의 5%의 경우 매우 적합합니다. 이러한 상황에서 DDD는 매우 힘든 너트를 깨뜨리는 데 도움이됩니다. 여기서 DDD는 관리자가 방금 책상을 가리키는 늑대 인간의은 총알 일 수 있습니다.

그것이 그것에 대한 소란이 이유입니다.

Answer 7

• 앱이 주로 데이터 중심이므로 아키텍처가 주로 기존 일 수 있습니다.

• 더 많은 논리 및 잠재적 영역 또는 가치 객체가있는 측면의 경우 DDD 아이디어 중 일부를 활용하여 코드를 구성 할 수 있습니다.

• 일반적으로 "사운드 대안"은 가능한 한 간단하게 유지하고 유용한 DDD 개념을 사용하고 기사에서 조언하는 것처럼 불필요하게 복잡하지 않습니다.

지금 비슷한 프로젝트를 시작하고 있습니다. 데이터 조작과 더 많은 논리/알고리즘 중심 영역이 혼합되어 있습니다. 나는 마찬가지로 프로젝트에 도움이 될 DDD의 일부를 가져 가고 싶지만 프로젝트가 비생산적 일 수있는 지역에서 강제로 강요하지는 않습니다.