DDD 그거 그렇게 하는 거 아닌데 - 느낀점 정리

영상 링크
https://youtu.be/sLG5n_pXWK0?si=J_oy-HVMpJkX5MMH

 

위 영상을 보고 느낀점 정리(너무 좋은 영상이었다. 보면서 깨닫는 것이 많았다)
DDD를 추구하는 사람으로써 실무에 어떻게 더 적용할 수 있을지 고민하면서 봤다

도메인 주도 설계 - 소프트웨어의 복잡성을 어떻게 다룰까?

MSA의 복잡성이 있기때문에 먼저 아래와 같이 시작하자
이점을 누릴 가능성이 크다고 생각하더라도 모놀리식으로 시작
야그니(정말 필요할때 까지 그 기능을 만들지 말라)

• 당연한 얘기지만 완벽한 설계는 존재하지 않는다
• OOP는 DDD의 기반이지만 동일하진않다
• 안티패턴. DDD를 모르는사람한테 전파한다면 거부감부터 들것이다

용어 사전
살아있는 문서로 만들기 위해 프로젝트 README.md 파일로 유지 관리할 수 있다
용어도 리뷰 대상이며 더 의미있는 용어를 지속적으로 찾자
개발 뿐 만 아니라 프로젝트의 모든 곳에서 이를 사용하도록 노력하자

느낀점
용어사전 좋은 것 같다. 나중에 회사에 적용할 수 있는 기회가 있으면 좋겠다
서로 생각하는 "용어"의 의미가 조금 달라 회의가 길어진 적이 있다.
단어 선택이 중요한 것을 깨닫고 추가로 내가 이해하고 있는 단어를 상대방도 동일하게 이해하고 있는 과정도 필요하다고 느낀적이 있다.
그래서 더더욱 용어의 중요성과 관리가 필요하다고 느꼈다

개발자는 비즈니스 도메인을 잘 몰라도 괜찮아요
내 월급은 어디서 나오나요?
내 월급은 비즈니스에서 나온다.
성공적인 비즈니스를 위해 어떻게 개발해야 하는가?

=> 크게 공감했다. 비즈니스를 모르고 설계, 개발을 할 수 있을까?
회사에서 가끔 비즈니스를 모른채 개발 소스 이관을하면서 놓친 점이 되게 많았다는 걸 느꼈다
추가로 그대로 따라가다 나중에 비즈니스를 좀 배우니 더 좋은 구조로 만들 수 있는 방법이 있다는 생각한 경험이 있다

결국 패키지 구조는 자연스럽게 도메인이 주도하는 아키텍처로 가게된다
처음부터 클린 아키텍처 , 헥사고날 아키텍처 적용해야한다고 소리치지 않아도된다

무언가를 도입하려면?
나를 도와줄 사람이 필요하다.
동맹이 있어야한다
호기심 유발 등 사람을 설득해야한다

느낀점
결국 내가 무언가를 도입하고 싶다면, 영상에 있듯이 정치를 하는 과정이 필요해보인다.
(영상에서도 말했지만 “정치”라는 단어 자체는 안좋게 얘기하는 것이 아니다)
나랑 맞는사람들이 있다면 같이 시너지를 내기 정말 좋을 것이다
하지만 내가 바꾸자하는 것은 소수의 인원으로 이루어 질 수 없다면,
그 사람들의 궁금증을 유발시키는 등 많은 사람을 내 편으로 “설득”을 해야한다.

DDD는 개발자만이 소프트웨어 개발에 참여하는 사람이 아니라는 점
프로젝트에 도움이 될 것이라고 생각되는 DDD아이디어를 얼마든지 적용
좋은 DDD는 “DDD에서는”으로 시작하지 않는다
DDD는 개발만 잘하는 것이 아니라 프로젝트도 잘하는 방법이다

느낀점
결론을 듣고 느낀점이 많았다.
무조건 개발에 도입해야해요가 아닌, 자연스럽게 적용하게 되는 과정이었던 것이다
프로젝트의 문제점을 찾아 이상향을 찾게된다면 그게 DDD로 가게될 것이라 한다
물론 무조건 맞는 얘기가 아닐수도 있긴하지만 현 시점으로는 DDD는 대다수가 지향하는 이상향으로 보이긴 한다
너무나도 당연한 말이지만 비즈니스 도메인 지향 관점이니까