시작하기에 앞서
안녕하세요.
대덕소프트웨어마이스터고등학교 2학년 Team Finda Backend의 변도휘, 박지민입니다.
본 글은 저희가 개발을 진행하기에 앞서 설계한 내용에 대해
조언과 피드백을 받고자 작성하게 되었습니다.
부족한 점이나 개선할 부분이 있다면 편하게 말씀해 주시면 감사하겠습니다.
1. 프로젝트 설명
Finda는 학교 봉사 활동을 효율적으로 관리할 수 있도록 돕는 웹·앱 기반 통합 플랫폼입니다.
선생님과 학생 모두 로그인하여 서비스를 이용할 수 있으며,선생님은 봉사 활동을 생성하고 학생들의 신청을 관리할 수 있습니다.
또한 봉사 시간을 조회·부여하고, 알림 전송 및 QR 코드를 활용한 출석 확인 기능을 사용할 수 있습니다.
학생들은 과거 봉사 활동을 조회하고 신청할 수 있으며, 마이페이지에서 유저의 정보와 누적 봉사 시간을 확인할 수 있습니다. 또한 선생님의 QR 코드를 스캔하여 간편하게 출석 체크를 할 수 있습니다.
선생님과 학생 모두 캘린더 기능을 통해 봉사 일정을 한눈에 확인할 수 있으며,
앱에서는 탭바의 Calendar 아이콘, 웹에서는 메인 페이지의 봉사 일정 확인하기 버튼을 통해 접근할 수 있습니다.
Finda는 봉사 활동 관리 과정을 디지털화하여 운영 효율을 높이고, 학생들의 봉사 참여를 보다 쉽고 적극적으로 만들어주는 서비스입니다.
2. 이전 상황
학교에서 기본적으로 DDD를 사용하고 있지만, DDD를 깊게 공부하기 전에 먼저 코드로 접했습니다. 그 결과 DDD에 대한 충분한 이해 없이 코드를 작성해 왔습니다.
따라서 Finda에서는 설계와 개발을 시작하기에 앞서서, 코드에 어떻게 DDD를 적용할지 제대로 학습하고 이해한 뒤에 개발을 진행할 것입니다.
3. 학습 계획
먼저 반 버논이 작성한 도메인 주도 설계 핵심(DDD)을 함께 읽고 도메인을 설계해보기로 했습니다.
책 정리 글은 너무 길어질 것 같아서, 다른 게시글로 게시하겠습니다.
4. DDD 설명
이해를 위해 간단하게 DDD를 설명하고 넘어가겠습니다.
DDD에서는 도메인이라는 용어가 매우 자주 언급됩니다.
먼저 DDD에서 설명하는 도메인이란, 비즈니스가 실제로 돌아가는 규칙과 개념, 그리고 그에 대한 지식의 집합을 의미합니다.
이러한 관점에서 DDD는 소프트웨어 설계에서 도메인 지식, 즉 비즈니스가 동작하는 규칙에 중심을 두는 소프트웨어 개발론이라고 할 수 있습니다. DDD에서는 기술적인 요소보다 도메인 지식이 가장 중요하게 다뤄집니다.
이를 위해 개발자는 도메인 전문가와 협력하며, 이 과정에서 유비쿼터스 언어와 같은 공통의 언어를 사용합니다. 또한 도메인 모델은 비즈니스 요구사항을 정확하게 반영하도록 설계됩니다. 이러한 특징으로 인해 DDD는 비즈니스와 기술 간의 차이를 최대한 줄이려는 설계 방식을 지향합니다.
5. 바운디드 컨텍스트의 정의
의미적으로 동일한 컨텍스트의 범위에 해당합니다.
해당 범주 안에서 소프트웨어 모델의 각 컴포넌는 특정한 의미를 갖고, 특정한 일을 수행합니다.
핀다에서는 세 개의 바운디드 컨텍스트를 두었습니다.
6. Finda에서 분리한 바운디드 컨텍스트
알림 바운디드 컨텍스트
- 알림 전송 바운디드 컨텍스트입니다.
봉사 바운디드 컨텍스트
- 봉사 신청 및 관리 컨텍스트으로 핵심 도메인에 속합니다.
사용자 관리 바운디드 컨텍스트
- 인증/인가 처리 및 사용자 관리 컨텍스트입니다.
7. 이렇게 분리한 이유
Finda에서는 시스템 간 결합도를 효과적으로 낮추기 위해
서로 다른 책임과 변경 특성을 가진 영역을 기준으로 바운디드 컨텍스트를 분리하였습니다.
봉사, 인증/인가(Auth), 알림은 모두 사용자와 연관된 기능이지만,
각각 담당하는 역할과 내부 규칙, 그리고 변경이 발생하는 이유가 명확히 다릅니다.
이러한 영역을 하나의 컨텍스트로 묶을 경우,
특정 기능의 변경이 다른 영역까지 불필요하게 영향을 미칠 수 있습니다.
먼저 봉사 컨텍스트는 신청, 승인, 출석, 완료와 같은 상태 전이 규칙을 중심으로 하는
서비스의 핵심 비즈니스 영역입니다.
이 영역은 학교 운영 정책 변화에 따라 규칙이 자주 변경될 수 있으므로,
다른 관심사로부터 독립적으로 보호될 필요가 있습니다.
반면 Auth 컨텍스트는 로그인, 토큰, 권한과 같은 보안 중심의 책임을 가지며,
인증 방식이나 권한 모델 변경과 같은 보안 정책 변화가 주요 변경 요인입니다.
또한 알림 컨텍스트는 메시지 템플릿, 채널, 재시도와 같은
전달 정책과 신뢰성이 핵심인 영역입니다.
메시지 정책 변경이 핵심 도메인에 영향을 주지 않도록,
봉사 도메인은 알림을 직접 호출하지 않고
봉사 신청 수락/거절 등과 같은 도메인 이벤트를 통해 간접적으로 연결됩니다.
8. 조언 부탁드립니다 🙇♀️
기존에는 DDD를 제대로 이해하지 못한 상태에서 개발을 진행했었기에
기초부터 다시 공부하며 적용 중입니다.
혹시 보시기에
“이건 좀 아닌데…”
싶은 부분이 있다면
조금만 시간 내서 한마디 남겨주시면 정말 감사하겠습니다. 🙇♀️
아직 많이 부족한 단계라
따끔한 조언도 감사히 듣겠습니다…!
긴 글 읽어주셔서 감사합니다.
대출그거 인줄알고 들어왓는데 ㅋㅋ
ㅋ