DDD에 대한 단상-1

책 내용을 인용합니다.

 

1. 개발자는 단지 코드를 작성하는 직업에 그치지 않으며 소프트웨어를 통해 문제를 해결하는 사람이라고 생각한다.

 

2. 코딩은 단지 하나의 측면일 뿐이다.

 

3. 좋은 디자인과 커뮤니케이션 능력은 매우 중요하다.

 

4. 아마도 소프트웨어 개발이란.. 뭔가를 넣으면 뭔가가 나오는 것이다 라고 생각해볼 때 garbage-in garbage-out 이라는 말을 생각해보자. 명확한 커뮤니케이션과 공유되는 도메인 지식을 통해서 garbage-in 을 최소화 하는 것은 중요하다.

 

5. DDD는 database-driven 도 object-oriented design 둘 다 아니다.

 

6. ddd가 모든 영역에서 적절한건 아니지만 비즈니스 소프트웨어를 만들어가는데는 적합하다.

 

7. 뭘 풀어내기 위해선 문제를 정확히 이해하는 것이 중요하다. 진짜로 제대로 이해하지 못했다면 올바른 해법을 만들어내기는 어려울 것이다. 슬픈 것은.. 도메인 전문가가 아닌 개발자가 만들어내야 한다는 것이다.

 

8. 요구사항이 적힌 문서를 통해서 개발 프로세스를 다루려 하지만 요런 방법은 때때로 문제를 가장 잘 아는 사람과 해법을 구현해야 하는 사람 간의 이해도의 차이가 생긴다. 해법을 구현해야 하는 사람은 개발자 뿐만이 아니다. UX, UI 디자이너, QA팀 모두 포함이다.

 

가족오락관에서 귀 막고 전달하는 것 마냥 개발 과정속에서 요구사항이 계속 와전되는 경우가 흔하다. 그걸 막기 위한 가장 좋은 방법은 중단다리를 제거하고 도메인 전문가는 개발 과정에서 친밀하게 속해서 지속적으로 피드백을 주고받는 것이다. 개발팀은 주기적으로 뭔가를 전달하고 빠르게 고쳐나가는 것이다. 다른말로 애자일이라고 한다.

근데 이런 방법도 문제가 될 순 있는데 왜내면 도메인 전문가의 소위 mental-model을 코드로 옮겨내는 일종의 번역 작업을 하는 꼴이고 나중에 코드 베이스로 일을 하게 될 개발자는 도메인 전문가의 도움 없이는 도메인을 이해하기 어려울 것이다.

다른 방법은 도메인 전문가나 개발팀이나 소스 코드 자체가 같은 모델을 공유하고 있다면..? 이런 경우에는 도메인 전문가의 요구사항을 번역할 필요가 없겠지. 오히려 직접적으로 적용한 코드가 될테니 더 좋다고 볼 수 있다. 그리고 이게 ddd의 목적이다.