인프런 커뮤니티 질문&답변

램쥐뱅님 안녕하세요. 조영호입니다.

좋은 질문 남겨 주셔서 감사합니다. 🙂

도메인 주도 설계와 강의 내용 사이의 관계

답변을 드리면 강의에서 설명하고 있는 내용들은 도메인 주도 설계와 무관하게 객체지향 패러다임만을 다루고 있다고 보시면 될 것 같아요. . 엄격하게 말하면 도메인 주도 설계에서 다루고 있는 범위와는 교집합이 없다고 보셔도 무방합니다. 책임 주도 설계, 도메인 모델, GRASP 패턴을 포함해서 강의에서 다루고 있는 모든 내용들은 에릭 에반스가 저술한 도메인 주도 설계가 출판되기 전에 나왔던 개념들이며, 오히려 도메인 주도 설계와 섞으면 초점이 흐려지고 혼란스러워지게 될 여지가 있습니다.

도메인 주도 설계는 특정한 프로그래밍 패러다임에 독립적입니다. 도메인 주도 설계는 도메인을 중심으로 소프트웨어의 복잡성을 극복할 수 있는 사고방식이자 우선순위를 결정할 때 참고할 수 있는 지침의 집합입니다. 도메인의 복잡성을 해결하기 위해 적용할 수 있는 패턴들의 집합이자, 패턴 언어라고 할 수 있습니다.

에릭 에반스가 도메인 주도 설계라는 개념을 정리할 때 객체지향 커뮤니티로부터 가장 많은 영향을 받았기 때문에, 책의 예제 대부분이 객체지향을 기반으로 서술되어 있기는 하지만(객체지향의 계약에 의한 설계와 책임 주도 설계를 혼합해서 전술적 설계를 설명하고 있습니다), 도메인 주도 설계와 객체지향 패러다임은 겹치는 부분이 그렇게 많지는 않습니다. 강의의 내용과 도메인 주도 설계 사이에서 굳이 교집합을 찾는다면 도메인에 포커스를 둔다는 정도인데, 이 부분은 에릭 에반스가 책에서 언급했던 것처럼 객체지향 커뮤니티가 도메인 주도 설계를 영향을 미친 부분 중에 하나라고 볼 수 있습니다.

유스케이스와 강의 내용 사이의 관계

유스케이스의 경우에는 다비 비에이라의 책에서도(제가 본 책은 쿼커스를 다루는 책이었는데 그 책을 말씀하시는건지 모르겠네요) 언급하기는 했지만, 실제로 유스케이스는 80년대 말에 시스템의 행위를 외부의 액터 관점에서 서술하기 위해 나온 개념입니다. 유스케이스는 이바 야콥슨이 처음 창시했고, 현대적인 유스케이스 서술 방식은 헥사고널 아키텍처를 제안한 앨리스테어 코어번이 정리했습니다. 유스케이스 다이어그램과 서술 방식은 나중에 이바 야콥슨이 표준 모델링 언어인 UML을 만드는 작업에 참여하면서 UML에 포함되게 됩니다.

유스케이스가 UML의 일부이기는 하지만 사실 개념적으로는 객체지향과 독립적인 요구사항 서술 방법이라고 보시는게 좋습니다. 많은 자료들이 시스템의 행위를 설명하기 위해 유스케이스를 예로 들어서 설명하기 때문에 다비 비에이라의 책에서 말하는 유스케이스는 UML에서 말하는 유스케이스와 동일하다고 보시면 됩니다.

강의에서는 유스케이스라는 용어를 '유스케이스 플로우'로 사용했는데요, 여기서 말하는 유스케이스 플로우는 유스케이스 다이어그램이나 유스케이스 디스크립션이 아니라 애플리케이션 로직이라고 보시면 됩니다. 일반적으로 유스케이스 다이어그램과 유스케이스 디스크립션은 유스케이스 플로우를 서술하기 위해 사용되기 때문에 유스케이스라는 용어를 공통으로 사용하기는 하지만 명확하게 두 개는 다르다고 보시면 될 것 같아요.

CRC 카드

CRC 카드는 켄트 벡과 워드 커닝험이 객체지향을 교육하기 고안한 방법인데요, 툴을 사용하지 않고 인덱스 카드 형태의 실제 종이를 사용합니다. 실제 인덱스 카드를 사용하는 이유는 카드를 이동시키면서 객체 사이의 협력을 커뮤니케이션하고 실험해 보기 위해서입니다. 몇몇 CRC 포맷을 지원하는 툴들이 있는 것으로 알고는 있는데, 다 마이너하고 제 경험이 제한적이다 보니 실무에서 실제로 사용되고 있는지까지는 알지 못합니다.

개인적으로 CRC를 가장 잘 사용하는 방법은 동료들과 협력 과정을 통해 설계를 빠르게 고안하고 검토하기 위해 실제 인덱스 카드를 사용하는 것이라고 생각합니다.

답변이 됐는지 모르겠네요. 🙂

안녕하세요, 인프런 AI 인턴입니다.

램쥐뱅님, 좋은 질문 감사합니다! 객체 지향 프로그래밍과 설계 방법론에 대한 이해를 돕기 위해 상세히 질문을 주셔서 감사합니다. 설계 방법론과 관련된 부분에 대해 말씀드리겠습니다.

객체지향 설계와 DDD

1. 객체지향 설계와 DDD(도메인 주도 설계):

   • 객체지향 설계는 객체들의 책임과 역할, 협력을 중심으로 시스템을 설계하는 방식입니다. GRASP 지침이나 책임 주도 설계 등이 이에 속합니다.
     
   • DDD는 복잡한 도메인의 문제를 해결하기 위한 설계 패턴입니다. 도메인 모델을 중심으로 비즈니스 로직과 도메인의 복잡성을 관리하는 방법론입니다.
     
   • 두 방법론 모두 객체의 역할을 중요시하며, 비즈니스 로직을 도메인 객체에 녹여내는 점에서 유사성을 보이지만, DDD는 비즈니스 로직의 복잡한 영역을 효과적으로 관리하기 위해 좀 더 풍부한 전략과 전술 패턴들을 제공합니다.
     

2. 아키텍처 패턴들:

   • 헥사고널 아키텍처는 비즈니스 로직과 인터페이스, 인프라스트럭처의 의존성을 분리하여, 시스템의 유연성과 유지보수성을 증대시키는 목적이 있습니다.
     
   • DDD에서도 애플리케이션 계층을 정의하여 도메인 로직과 외부 시스템 통합을 고려하는 방법론을 제시합니다.
     

3. 더 나은 설계 방법 정리:

   • 많은 설계 방법이 존재하고 이러한 방법들은 문제의 복잡도와 팀의 이해관계자에 따라 선택적으로 적용됩니다. 주로 프로젝트 시작 전 설계 방식을 다각도로 검토 후, 그 프로젝트에 가장 맞는 설계 방식들을 조합하여 사용하게 됩니다.
     

CRC 카드 작성 도구

CRC 카드 작성은 협력적이고 인터렉티브한 형태로 진행하는 것이 좋습니다. 일부 유용한 도구를 소개합니다:

• Sticky Notes: 현실적인 작은 프로젝트에서는 오프라인에서 포스트잇을 활용해 손쉽게 카드 작성이 가능합니다.
  
• Miro, Trello: 온라인 팀 협업 툴로, CRC 카드를 온라인 상에서 시각화하고 팀과 실시간으로 협업이 가능합니다.
  
• Google Docs 또는 Sheets: 각 셀이나 패널로 CRC 카드를 관리하여 복사, 공유, 협업을 효율적으로 할 수 있습니다.
  

아래 링크를 통해서도 관련 주제에 대한 토론과 답변들을 활용하시면 도움이 될 것입니다.

• 실제로 객체지향으로 설계를 많이 하는지 궁금합니다.
  

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.