Page History

요약

1-DDD, 소프트웨어 복잡성을 다루는 지혜

Image Added

• DDD는 소프트웨어의 복잡한 문제를 해결하기 위한 방법론이자 철학과 같아요 .이름 자체보다는 "소프트웨어의 복잡성을 다루는 지혜"라는 부제가 DDD의 진짜 의미를 잘 보여줘요 .즉, 단순히 코드만 짜는 기술이 아니라, 문제를 어떻게 바라보고 해결할지에 대한 깊은 고민을 담고 있죠 .
• DDD는 객체 지향이나 시스템의 자율성 같은 개념을 기반으로 하고 있어요 .
• 프로젝트의 처음부터 끝까지, 모든 단계에 적용해서 도움을 받을 수 있는 도구랍니다 .

DDD 도입, 이렇게 하면 망해요! (흔한 함정)

Image Added

• DDD를 시작할 때 "헥사곤 아키텍처나 클린 아키텍처를 꼭 써야 해!"라고 하거나 , "일단 마이크로서비스로 다 쪼개고 보자!"라고 하는 건 금물이에요 .특히 처음부터 MSA를 성급하게 도입하면 "마이크로서비스 프리미엄"이라는 복잡성 증가에 시달릴 수 있어요 .서로 자주 통신해야 하는 서비스들을 물리적으로 분리해 놓으면 오히려 난감한 상황이 생기거든요 .
• 또 "완벽한 설계를 해야만 도입할 수 있다"고 생각하는 것도 큰 착각이에요 .완벽한 설계란 세상에 존재하지 않아요 .우리가 만드는 소프트웨어나 사용자의 요구사항은 계속 변화하니까요 .
• 처음부터 너무 어려운 용어(예: TDD, BDD, ATDD 등)를 꺼내면 팀원들이 "오스트랄로피테쿠스"를 만난 것처럼 거부감을 느낄 수 있어요 .

맨땅에 DDD 시작하기 (그린필드)

 Image Added

• 그린필드 프로젝트는 마치 빈 도화지 같은 상태를 말해요. 아무것도 없는 상태에서 시작하죠 .이럴 때는 일단 코드를 짜면서 도메인 지식을 충분히 얻는 게 중요해요 .
• 처음부터 멋진 설계를 하려고 애쓰기보다, 일단 게터(Getter)와 세터(Setter) 같은 것을 사용해서 구현을 시작해도 괜찮아요 .코드를 보면서 "어떻게 하면 좀 더 의미 있는 코드가 될까?" 고민하고 점진적으로 리팩토링해나가세요 .이렇게 하다 보면 자연스럽게 빈약했던 도메인 모델이 풍부해진답니다 .

유비쿼터스 언어, 왜 필요할까요? (모두 같은 말 사용하기)

Image Added

• 유비쿼터스 언어는 프로젝트에 참여하는 모든 사람이 같은 용어를 사용하는 걸 말해요 .개발자, 기획자, 디자이너 등등 누구나 어디서든 똑같은 단어로 이야기하는 거죠 .
• 용어 사전처럼 사용하는 단어들을 기록해 두면 좋아요 .명사뿐만 아니라 동사도 중요해요 .리드미 파일처럼 소스코드와 함께 관리하면 항상 최신 상태를 유지할 수 있답니다 .
• 용어 정의는 단순히 사전적 의미만 적지 말고, 실제 예시를 함께 적으면 이해하기 훨씬 쉬워져요 .예를 들어, '과제'라는 단어가 저희에게는 "풀어보세요"지만, 학생들에게는 "제출하는 것"일 수 있으니 명확히 구분하는 것처럼요 .
• 이렇게 용어를 명확히 정의하면 인수 조건 등을 만들 때도 도움이 되고, 반대로 인수 조건을 만들면서 용어를 더 깊이 이해할 수도 있어요 .

기존 코드에 DDD 적용하기 (브라운필드)

 Image Added

• 브라운필드 프로젝트는 이미 오랜 시간 개발된 코드가 있는 상태를 뜻해요 . 어제까지 짠 코드도 오늘부터는 레거시가 될 수 있죠 .
• 개발자는 비즈니스 도메인을 잘 알아야 해요 .우리 회사가 어떻게 돈을 버는지, 소프트웨어가 어떤 문제를 해결하는지를 알아야 한다는 뜻이에요 .비즈니스 도메인을 이해해야 우리 개발 방향을 제대로 설정하고, 어디에 자원(인력, 시간)을 집중할지 결정할 수 있어요 .
• 비즈니스 도메인은 보통 너무 크기 때문에, 상품, 주문, 결제처럼 더 작은 하위 도메인으로 쪼개서 이해해야 해요 .
• 이렇게 복잡한 문제를 해결할 때는 분할과 정복처럼 문제를 작은 덩어리로 나누는 것이 기본이에요 .

바운디드 컨텍스트와 전략적 설계 (경계 나누고 협업하기)

 Image Added

• 문제를 해결하기 위해 우리가 다루는 영역에 경계를 짓는 것을 바운디드 컨텍스트를 나눈다고 표현해요 .
• 경계를 나누는 기준은 크게 두 가지예요 .같은 단어라도 다른 의미로 사용될 때(예: 과제) .외부 시스템이 우리 시스템에 영향을 줄 때 .
• 어떻게 경계를 나눌지는 팀원들마다 생각이 다를 수 있어요 .팀원들이 각자 생각하는 경계를 그려보고 함께 이야기 나누는 것이 중요해요 .
• 경계를 나눌 때는 한 번에 전부 나누기보다, 가장 작은 부분이나 가장 중요하거나 영향력이 적은 부분부터 점진적으로 분리해나가세요 .
• 이런 경계 나누기와 팀 간의 협업 방식을 논의하는 것을 DDD에서는 전략적 설계라고 부른답니다 .

외부 시스템과의 단절 (방패 만들기)

Image Added

• 우리 시스템이 외부 시스템 (결제 서비스, 로그인 등) 때문에 휘둘리지 않도록 방패를 만들어야 해요 .이 방패 역할을 하는 세 가지 패턴이 있어요: DTO, DIP, ACL .특히 ACL (부패 방지 계층)은 외부 시스템의 용어나 지식이 우리 시스템으로 들어오지 못하게 막거나 번역해주는 역할을 해요 .
• 이런 방패 패턴들을 적용하다 보면, 자연스럽게 우리의 코드가 도메인 주도 아키텍처 형태로 발전하게 돼요 .처음부터 복잡한 아키텍처를 목표하기보다, 일단 코딩하고 필요한 부분을 리팩토링하면서 자연스럽게 도메인 주도 형태를 만드는 것이 중요해요 .

DDD, 어떻게 팀에 도입할까요? (변화를 위한 노력)

 Image Added

• DDD를 성공적으로 도입하려면 변화를 이끌어 줄 사람이 필요해요 .
• 팀원들과 동맹을 맺고, 다양한 마케팅 기법을 활용해서 DDD에 대한 호기심을 유발하세요 .
• 예를 들어, 팀원들이 자주 지나다니는 화이트보드에 DDD 관련 그림을 슬쩍 그려두는 것도 좋은 방법이에요 .그림을 본 팀원들이 궁금해서 물어보면 그때 이야기해주면서 자연스럽게 논의를 시작하는 거죠 .

DDD, 결국 무엇일까요? (코딩 넘어 프로젝트 잘하기)

• DDD는 단순히 개발자만의 기술이 아니라, 프로젝트에 참여하는 모든 사람과 관련된 이야기예요 .
• 가장 중요한 건 "DDD로 시작하지 않는 것"이에요 .우리에게 왜 필요한지 고민하고, 필요한 부분부터 하나씩 적용하다 보면 자연스럽게 DDD를 하게 될 거예요 .
• DDD는 단순히 코딩만 잘하게 해주는 게 아니라, 프로젝트 전체를 잘하는 방법이랍니다 .
• DDD 자체 책 말고도 '소프트웨어 장인', '팀 토폴로지' 같은 책들을 읽어보면 더 많은 아이디어를 얻을 수 있을 거예요 .