헥사고날아키텍처
-
[클린 아키텍처 04] 유스케이스 구현하기프로그래밍/기타 2024. 8. 26. 23:18
>유스케이스 구현하기유스케이스 둘러보기유스케이스를 구성하는 단계는 다음과 같다. 1. 입력을 받는다2. 비즈니스 규칙을 검증한다.3. 모델 상태를 조작한다.4. 출력을 반환한다. 입력 유효성 검증입력 유효성 검증은 어디에서 해야하는가? 바로 입력 모델이다.input parameter로 들어오는 모델(입력 모델)에서 입력 유효성 검증을 수행한다.해당 모델의 위치는 use case의 위치와 같다! because use case api의 일부이기 때문에! @Value@EqualsAndHashCode(callSuper = false)publicclass SendMoneyCommand extends SelfValidating { @NotNull private final AccountId sourceA..
-
[클린 아키텍처 03] 코드 구성하기프로그래밍/기타 2024. 8. 26. 22:10
>코드 구성하기계층으로 구성하기Web, Domain, Persistence의 구조로 패키지를 구성한다.요렇게 구성하는 경우의 문제점은? 1) 기능이나 특성을 구분짓는 경계가 없음 만약 User 기능이 추가 된다면...?서로 연관되지 않은 기능끼리 마구마구 섞임 (domain 패키지에 user repo, service, user entity 모두 추가됨 ㄷㄷ) 2) 어떤 유스케이스가 있는지 파악 불가AccountController에는 어떤 기능이 있을까..? User Controller에는..?기능으로 구성하기Account 패키지 안에 몽땅 넣는다!그 와중에 AccountService 네이밍을 SendMoneyService로 변경함이렇게 구성할 경우 '송금하기' 기능이 어딨는지 파악 가능하긴 함.. 그러..
-
[클린 아키텍처 02] Dependency Inversion (의존성 역전하기)프로그래밍/기타 2024. 8. 16. 15:34
> 의존성 역전하기백엔드 개발자라면,, 누구나 한번쯤 달달달 외웠을 SOLID 원칙! 그 중 단일 책임 원칙과 의존성 역전 원칙에 대해 자세히 살펴보도록 합시당 단일 책임 원칙우리가 흔히 아는 단일 책임 원칙은 하나의 컴포넌트는 오로지 하나의 역할만을 해야한다는 것이다.그러나 클린 아키텍처의 저자는 단일 책임 원칙을 요로케 표현했당:컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다. 컴포넌트가 변경되는 이유가 오직 하나 뿐이라면 우리가 다른 이유로 소프트웨어를 변경하더라도 이 친구는 절대 변하지 않는다는 것이다; 요렇게 세 개의 클래스가 있을 때,만약 C가 어떤 함수명을 바꿨다. 그럼 그 친구를 참조하고 있던 A와 B도 어쩔 수 없이 바꿔야함 ㅠ_ㅠ 👎👎👎C는 어느 곳에도 의존하지 않기 때문에 지..