프로그래머의 업무는 소프트웨어로 문제를 해결하는 것으로서, 코딩은 소프트웨어 개발의 한 측면일 뿐. 좋은 디자인과 의사소통은 코딩 못지 않게 중요함.

소프트웨어 개발을 요구사항이라는 입력을 받아서 최종 결과를 출력하는 프로세스로 생각해본다면, 여기에도 ‘쓰레기를 넣으면 쓰레기가 나온다 garbage in, garbage out 는 법칙이 적용됨. 불분명한 요구사항이나 잘못된 디자인과 같은 옳지 않은 입력으로는 어떤 코드도 원하는 결과를 생성해내지 못함.

이책의 1부에선 명확한 커뮤니테이션과 도메인 지식 공유를 위한 디자인 방법론인 도메인 주도 설계로 어떻게 ‘쓰레기를 넣는’ 부분을 최소화할지 알아봄.

• DDD 원칙을 먼저 논의한 뒤 이를 특정 도메인에 어떻게 적용하는지 살펴보는 시간과 함께 시작
• DDD는 깊게 들어가지는 않지만, 이 장이 끝나면 적어도 도메인 주도 설계를 어떻게 수행하고 데이터베이스 주도 설계, 객체지향 프로그래밍과 어떻게 다른지 감을 잡을 수 있음

DDD가 모든 소프트웨어 개발에 적합한 것은 아님. 소프트웨어는 시스템 소프트웨어, 게임 등 다양한 종류가 있으며, 각각 알맞은 방법을 택해 개발할 수 있음. 다만, 비즈니스와 기업용 소프트웨어 같이 개발자가 다른 비개발팀들과 협력해야 하는 경우에는 DDD가 유용함.

1.1 공유 모델의 중요성

문제를 풀기에 앞서 문제를 바르게 이해하는 것이 중요함. 문제를 왜곡하거나 충분히 이해하지 못했다면 분명히 유용한 설루션을 제공하지 못할 것. 여기서 말하는 이해는 당연히 도메인 전문가가 아니라 제품에 반영되는 개발자의 이해를 가리킴.

그러면 개발자가 문제를 정말로 이해했는지 어떻게 보장하나?

이를 해결하고자 몇몇 개발 방식에서는 소프트웨어 명세와 요구사항 문서로 문제의 모든 디테일을 담아내고자 함

→ 안타깝게도 이 방식은 문제를 가장 잘 이해한 사람부터 설루션을 개발하는 사람까지의 거리를 종종 멀어지게 만들고함

→ 후자를 ‘개발팀’이라 부르는데, 단순히 개발자뿐만 아니라 UX, UI 디자이너, 테스터 등 개발에 참여한 모든 이들을 통칭함

→ 전자는 ‘도메인 전문가’라 지칭함