Category Architecture

상태를 가진 도메인을 개발할 때 가장 흔한 구조는 엔티티에 status 컬럼을 두고, 서비스 코드에서 if (course.getStatus() == DRAFT) 같은 조건문으로 전이를 검사하는 방식이다. 처음에는 잘 동작한다. 문제는 그 강의를 다루는 코드가 두 곳, 세 곳으로 늘어날 때다. 어느 상태에서 어느…

아키텍처 규칙은 대부분 문서에만 있다. “슬라이스 사이에는 순환 의존을 두지 않는다”고 적어 놓고, 코드 리뷰에서 걸러 내기를 기대한다. 그런데 리뷰어가 놓치면 그대로 들어가고, 한 번 들어간 순환 의존은 시간이 지날수록 걷어 내기 어려워진다 결론부터 말하면 이런 규칙은 테스트 코드로 강제할…

테스트 픽스처를 열어 보면 이런 코드가 있다 닉네임은 KimWhat이고 비밀번호는 verysecret이다. 이 값이 무슨 의미인지는 아무도 설명하지 않는다. 그냥 형식 검증을 통과할 만한 길이로 아무렇게나 정한 값이다. 그런데 이 값은 검증 코드에도 그대로 박혀 있다 이 테스트가 통과한다고 해서 비밀번호…

애플리케이션 서비스 클래스를 하나 열어 보면 이런 상태가 되어 있다 네 줄 모두 이 클래스가 무슨 일을 하는지에 대한 설명이 아니다. 스프링 빈으로 등록하고, 트랜잭션을 걸고, 파라미터 검증을 켜고, 생성자를 만들어 달라는 지시다. 애플리케이션 서비스를 새로 만들 때마다 이 네…

헥사고날 아키텍처를 배우고 나면 안과 밖의 경계는 선명해진다. 어댑터는 밖에, 도메인은 안에. 포트로만 소통한다. 그런데 정작 실무에서 막히는 지점은 그 다음이다. 회원 하나만 있을 때는 헥사곤 하나로 충분했는데, 강사가 들어오고 강의가 들어오면 헥사곤 안쪽이 금세 뒤엉킨다. 여기서 자연스럽게 떠오르는 발상이…