도메인 설계
8개 도메인이 무엇을 책임지고 어떻게 이어지는지. 그림은 실제 build.gradle 과 어댑터에서 뽑은 값으로 그립니다.
① 전체 지도 — 도메인과 실행 서버
서버는 둘이다. wvctesol-auth 가 신원을 확인해 토큰을 발급하고, wvctesol-api 는 그 토큰을 검증만 한다. 발급과 검증을 나눠 두면 API 서버가 늘어도 비밀키를 쥔 곳은 하나로 남는다.
도메인 간 직접 의존은 두 개뿐이다 — commerce → catalog(주문이 가격을 읽는다), identity → notification(아이디 안내를 보낸다). 나머지는 서로를 모른다. 함께 봐야 하는 것은 shared/common-domain 에 둔다.
② 계층 — 화살표 방향이 규칙이다
domain 은 스프링도 JPA 도 모른다. 그래서 테스트가 빠르고, 프레임워크를 바꿔도 규칙이 남는다. infrastructure 가 domain 의 포트를 구현하므로 화살표가 안쪽을 향한다 — 의존이 뒤집히는 지점이다.
계층별 의존 대상
| 계층 | 의존 | 하는 일 |
|---|---|---|
domain | shared/common-domain 만 | 스프링도 JPA 도 모른다. 순수 자바다 |
app | domain + 다른 도메인의 app/domain | 유스케이스와 트랜잭션 경계 |
infrastructure | domain + app | JPA 어댑터. 레거시 표현 변환이 여기서 끝난다 |
web | domain + app | HTTP 경계. infrastructure 를 모른다 |
web 이 infrastructure 를 모르는 것이 중요하다. 컨트롤러가 EntityManager 를 직접 쓰기 시작하면 계층이 무너진다 — 실제로 관리자 계정 조회를 만들 때 그렇게 썼다가 되돌렸다.
③ 수강권 — 도메인을 가로지르는 흐름
이 서비스에서 가장 중요한 상태는 수강권이다. 돈을 낸 사람만 강의를 보고 시험을 칠 수 있다. 그 값을 commerce 가 켜고 learning · assessment 가 읽는다 — 세 도메인이 member 한 테이블을 통해 이어진다.
admin/member/mb_proc.php 에서 손으로 켰다. 카드 승인·입금 확인 시 자동으로 여는 것은 이쪽에서 정한 규칙이다.④ 함께 보는 테이블
레거시 스키마를 그대로 쓰기 때문에 한 테이블을 여러 도메인이 본다. 이 지점이 도메인 경계가 흐려지기 쉬운 곳이라 그림으로 드러내 둔다.
member 를 넷이 본다. 다만 쓰는 것은 identity 와 commerce 뿐이고 나머지는 읽기만 한다. apply 는 assessment(레벨테스트 신청)와 marketing(상담 관리)이 각각 다른 관점으로 본다.
⑤ 마케팅 콘텐츠
⑥ 공용 모듈 — 무엇을 shared 에 두는가
기준은 하나다. 여러 도메인이 함께 봐야 하는 것만 둔다. 편해서 두는 게 아니다 — shared 가 커지면 모든 도메인이 그것에 묶인다.
| 모듈 | 담은 것 | 왜 여기 있는가 |
|---|---|---|
common-domain값 객체와 도메인 예외 | CourseCodeEntitlementsDomainException 외 4종 | Entitlements 는 identity 가 만들고 assessment · learning 이 판정에 쓴다. 한쪽에 두면 반대편이 그 도메인을 통째로 의존해야 한다. |
common-security요청 주체 | ActorRequireAdmin | 조회는 언제나 Actor 기준이다. 컨트롤러가 받은 파라미터로 남의 자료를 열지 않게 한다. |
common-web응답 포맷과 예외 변환 | ApiErrorPageResponseGlobalExceptionHandler | 예외 종류가 곧 상태 코드다. 컨트롤러마다 상태 코드를 정하지 않는다. |
common-utils레거시 표현 변환 | LegacyFormat | varchar(14) 'YYYYMMDDHHmmss' 날짜와 Y/N 플래그를 여기 한 곳에서만 다룬다. |
common-app유스케이스 공통 타입 | PageRequest | - |
common-infrastructure영속성 공통 설정 | - |