- 프로젝트 기간 : 2026.01.12 ~ 2026.02.12
- 기능 구현 기간 : 2026.01.28 ~ 2026.02.11
- GitHub Issues와 Jira를 사용하여 진행 상황을 공유했습니다.
- 누구나 자유롭게 표현
- 폰트를 통해 자신의 감정과 메시지를 쉽게 표현할 수 있도록 설계
- 일상 속 접점 확대
- QR기반 방명록을 통해 별도의 학습 없이 자연스럽게 폰트 경험 유도
- 매장별 방명록 판
- QR코드로 누구나 빠르게 접근
- 오프라인 공간을 디지털 경험으로 확장
- 로그인 없이도 작성 가능
- 회원은 작성 기록 관리 가능
- 사장은 방명록 관리(삭제) 가능
- 방명록 작성 시 즉시 화면 반영
- WebSocket 대신 SSE 기반 단방향 이벤트 처리
- 전체 폰트 조회
- 태그 기반 필터링
- AI기반 폰트 추천 (텍스트/검색 기반)
- 주변 매장 조회
- 최신 방명록 조회
📦 src
├── 📂 main
│ ├── 📂 java/com/solinone/todoc
│ │
│ │ ├── 📂 board # 방명록 판(생성, 조회, 관리)
│ │ │ ├── 📂 presentation # Controller (API 계층)
│ │ │ ├── 📂 application # Service 계층
│ │ │ ├── 📂 domain # Entity
│ │ │ ├── 📂 infrastructure # Repository 인터페이스
│ │
│ │ ├── 📂 content # 방명록 내용(작성, 삭제, 조회)
│ │ │ ├── 📂 presentation
│ │ │ ├── 📂 application
│ │ │ ├── 📂 domain
│ │ │ ├── 📂 infrastructure
│ │
│ │ ├── 📂 place # 매장(사업자 등록, 매장 생성, 지도 조회)
│ │ │ ├── 📂 presentation
│ │ │ ├── 📂 application
│ │ │ ├── 📂 domain
│ │ │ ├── 📂 infrastructure
│ │
│ │ ├── 📂 font # 폰트 조회 및 추천 기능
│ │ │ ├── 📂 presentation
│ │ │ ├── 📂 application
│ │ │ ├── 📂 domain
│ │ │ ├── 📂 infrastructure
│ │
│ │ ├── 📂 user # 사용자(회원가입, 로그인, 마이페이지)
│ │ │ ├── 📂 presentation
│ │ │ ├── 📂 application
│ │ │ ├── 📂 domain
│ │ │ ├── 📂 infrastructure
│ │ │ ├── 📂 dto
│ │ │ ├── 📂 exception
│ │ ├── 📂 global # 공통 설정 (보안, 예외, 응답 포맷 등)
│ │ ├── 📂 infrastructure # S3, SSE, 외부 API 등 공통 인프라 구현
│ │ └── TodocApplication.java # 메인 실행 파일
│ ├── 📂 resources
│ │ ├── application.yml
│ │ ├── application-dev.yml
│ │ ├── application-local.yml
│
└── README.md
본 프로젝트는 도메인 중심 설계를 지향하며, 각 기능을 도메인 단위로 분리하고 내부를 4계층으로 구성했습니다.
- presentation : API 요청/응답 처리 (Controller)
- application : 유스케이스 실행 및 비즈니스 흐름 제어
- domain : 핵심 비즈니스 모델 및 규칙
- infrastructure : DB, 외부 API, S3, SSE 등 구현체
- 도메인 구조(DDD 스타일) 설계 제안 및 적용
- SSE 기반 실시간 이벤트 설계/구현
- QR 코드 생성 로직 및 S3업로드 모듈 구현
- 공통 응답 포맷 및 전역 예외 처리 정리
PostgreSQL을 사용했지만 JSONB,인덱싱 전략 등 고유 기능을 적극적으로 활용하지 못했다. 단순 RDBMS 수준으로 사용한 점이 아쉬움으로 남는다.
도메인 중심 구조를 지향했지만 완전한 Aggregate 분리와 명확한 경계 설정까지는 도달하지 못했다.
초기에는 도메인 간 ID 참조 방식을 유지하려 했으나, 팀의 숙련도와 일정 제약으로 인해 일부 관계를 @ManyToOne 기반 연관관계로 구현했다.
DDD를 적용한다고 해서 반드시 좋은 설계가 되는 것은 아니며, 프로젝트의 목적과 상황을 고려한 현실적인 선택 또한 중요한 설계 결정이라 생각한다.
향후 리팩토링에서는 다음을 개선할 계획이다.
- Aggregate 경계 재정의
- 도메인 간 ID기반 참조 일관성 확보
- 연관관계 최소화를 통한 도메인 독립성 강화