행운개발자의 블로그

아키텍처에 관심을 가지게된 이유 결론적으로는 개발하는 프로젝트의 복잡도가 증가하면서 수정하는 비용이 커졌기 때문입니다. 비즈니스 요구사항이 점점 복잡해지면서 사용자 관점의 유즈케이스를 코드만 보고 파악하기 어려워졌습니다. 기능 하나를 수정하면 영향을 받는 코드가 많아서 수정하기 어렵기도 하고 수정한 결과에 대한 심리적 안정감도 많이 떨어졌습니다. “수정하기 쉽도록 프로젝트를 구성하려면 어떻게 해야할까?”라는 의문에 답을 찾기 위해서 클린 아키텍처를 떠올렸고, 구체적인 예제 코드를 제공한다는 이야기를 듣고 책 ‘만들면서 배우는 클린 아키텍처’를 읽어보게되었습니다. 이번 글은 책 ‘만들면서 배우는 클린 아키텍처’를 2번 정독하고, 토이프로젝트를 직접 진행해보면서 배우고 느낀 것들에 대해서 이야기합니다. 수정..

헥사고날 아키텍처를 적용해보면서 제가 직접 고민하고 깨닫고 실수했던 사항들입니다. 직접 프로젝트를 하면서 생각나는 부분들이 있으면 채워두겠습니다. 구조 관점 멀티 모듈에서 모듈은 배포 단위로 구성하는 것이 좋습니다. 프로젝트가 모듈 A,B,C로 나누어져있고 모듈 C가 모듈 A,B를 의존하고 있는 상황이라면 하나의 모듈 안에 패키지 구조로 세부 도메인 A,B,C를 나누는 것을 고려해보아야합니다. 세부 도메인을 별도의 모듈로 나누는 시점은 배포를 따로 해야하는 타이밍일 수 있습니다. 애플리케이션 계층 트랜잭션 처리는 애플리케이션 계층에서 이루어저야한다. @Transactional을 사용한다면 AOP의 특징을 반영한 아래의 주의 사항을 참고하자 // TODO @Transactional 사용시 주의사항 트랜잭션..

객체 중심의 개발의 문제점 애플리케이션이 성장하면서 그 내부의 복잡도는 점점 커집니다. 개발자들이 도메인 영역을 객체지향 중심적으로 잘 구성한다고 하더라도, 복잡한 객체가 될수록 객체의 행위를 데이터베이스에 저장하는 과정도 함께 복잡해집니다. 객체지향은 행동을 중심에 두고, 관계형 데이터베이스는 데이터를 중심에 두기 때문에 이 둘 사이의 불일치가 존재합니다. 유연하고 확장 가능하도록 객체지향 설계를 향해 나아갈수록 데이터 중심의 데이터베이스와 거리가 멀어집니다. 추상화, 캡슐화, 정보은닉, 상속, 다형성 등 애플리케이션 개발에서 사용되는 다양한 장치들이 데이터베이스에는 정확하게 매핑되는 개념이 없기 때문입니다. 객체를 관계형 데이터베이스에 저장하고 조회하는 과정에서 개발자는 무수히 많은 코드를 작성하고 ..

헥사고날 아키텍처의 테스트 테스트는 비용이 적고, 유지보수가 쉽고, 빨리 실행되어야 합니다. 그래서 테스트 피라미트가 등장했습니다. 단위 테스트 - 통합 테스트 - 시스템 테스트가 순서대로 있습니다. 단위 테스트는 가장 밑에서 가장 넓은 영역을 차지합니다. 시스템 테스트는 가장 비용이 높은 테스트로서 커버리지의 목표가 통합 테스트와 유닛 테스트보다 좁아야 합니다. 모든 영역의 테스트에서 커버리지를 높게 잡으면 새로운 기능을 만드는 것보다 테스트를 만드는데 더 시간을 쓰게 됩니다. 유닛/통합/시스템 테스트는 각각 클래스/연결된 여러 컴포넌트/모든 컴포넌트를 검증합니다. 단위 테스트 단위 테스트를 수행할 때에는 의존성이 있는 컴포넌트의 동작을 mocking 합니다. 그리고 테스트 대상이 모킹하고 있는 의존 ..

헥사고날 아키텍처의 영속성 계층 영속성 계층 Adapter의 동작 방식 일반적인 의존성 역전을 사용한다면 Service 계층에서 Repository 인터페이스를 호출하고 실질적으로는 RepositoryImpl이 동작합니다. Service -호출→ Repository -구현→ RepositoryImpl 이러한 의존성 역전을 한 번 더 꼬은 것이 Adapter입니다. Adapter는 애플리케이션 계층의 port 인터페이스를 상속한 Repository가 사용되는 곳입니다. Service -호출→ Port -구현→ Adapter -호출→ Repository -구현→ RepositoryImpl package io.lucky.user.persistence.adapter; import io.lucky.user.app..

헥사고날 아키텍처의 애플리케이션 계층 애플리케이션의 UseCase 웹 계층에 들어온 요청은 UseCase 인터페이스를 통해서 Service 계층에 전달되고 Port를 통해서 모델의 상태를 변환하고 출력을 반환한다. UseCase를 애플리케이션을 사용하는 하나의 흐름이라는 관점에서 이 과정을 정리해보면 4단계로 구성된다. 입력을 받기 (web) 검증하고 비즈니스 로직 수행하기 (usecase + service) 모델 상태를 조작하기 (port) 출력을 반환하기 (web) 검증의 과정은 입력받은 값 자체에 대한 검증이 필요하기도 하고, 비즈니스 상의 검증 로직도 필요하다. usecase를 구현한 service가 비즈니스 상의 검증 로직만을 담당하도록 책임을 부여한다면, 입력 유효성 검증은 어디에서 수행되어야..

간소화된 헥사고날 아키텍처 패키지 구조 헥사고날 아키텍처로 검색하면 많이 보이는 그림이 있습니다. 그리고 만들면서 배우는 클린 아키텍처라는 책에서는 패키지 구조를 어떻게 설계해야하는지에 대한 구체적인 방안을 제공하고 있습니다. 하지만 아직 제 경험으로는 이러한 그림과 패키지 구조 전체를 전체로 다 활용할 수 있을만큼의 경험이 부족한 것 같습니다. 거의 50%는 왜 있는지 모르겠고 불필요해보였습니다. 그래서 제가 필요성을 느끼는 부분만 남겨서 보았습니다. io.lucky.user web controller dto request response application usecase query service port domain persistence adapter mapper repository Main.jav..

핵사고날 아키텍처 중심으로 향하는 의존성 방향 핵사고날 아키텍처는 의존성 역전 원칙을 적용해서 애플리케이션 계층으로 의존성이 생기도록 구성합니다. 계층형 아키텍처에서 웹 → 도메인 → 영속성으로 의존성이 존재했다면, 핵사고날 아키텍처에서는 웹 → 도메인 ← 영속성 방향의 의존성을 가집니다. 의존성 방향이 도메인 계층을 향하면 웹과 영속성 계층의 기술에 의존하지 않고 비즈니스 로직을 작성할 수 있습니다. SpringBoot, JPA라는 한국형 국룰 조합을 사용한다고 하더라도 이러한 의존성 방향을 가져갈 이유가 있습니다. 하나의 애플리케이션이 더 작은 애플리케이션들로 나누어지는 경우에도 이러한 의존성의 방향이 도움을 줍니다. 도메인이 웹, 영속성 계층에 상관없이 독립적으로 작성되어 있기 때문에 비즈니스 요구..

계층형 아키텍처 극복하기 단일 책임 원칙과 의존성 역전 원칙 단일 책임 원칙은 하나의 컴포넌트는 오로지 한 가지 일을 해야하고, 그것을 올바르게 수행해야 한다는 뜻으로 알려져 있습니다. 그런데 단일 책임 원칙의 실제 정의는 “컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다.” 입니다. 단일 책임 원칙을 좀 더 깊게 이해하기 위해서 단계적으로 들어가보겠습니다. 우선 웹 - 도메인 - 영속성의 구조를 가지는 게층형 아키텍처에서 서비스 규모가 매우 커진 상황을 가정합니다. 도메인이라는 거대한 층은 엄청나게 많은 비즈니스 로직들을 담고 있습니다. 도메인이라는 하나의 계층에서 각자의 역할을 하는 컴포넌트를 정의하고 컴포넌트 A에서 컴포넌트 B,C,D 를 사용하는 것은 당연합니다. A에서 B,C,D를 사용하는 것..

계층형 아키텍처의 문제점 계층형 아키텍처 그림 웹 - 도메인 - 영속성 데이터베이스 중심의 설계를 유도한다 계층형 아키텍처에서 웹 계층을 도메인 계층에 의존하고, 도메인 계층은 영속성 계층에 의존합니다. 결국 자연스럽게 데이터베이스에 의존하게 됩니다. 데이터베이스 중심의 개발은 사용자의 행위보다는 상태에 더 집중하게 만듭니다. ‘계정이 잠기면 이런 저런 행위를 하지 못한다.(행위)’ 보다 ‘계정의 상태가 LOCKED 일 때에는 이런 저런 행위를 하지 못한다.’ 라는 생각을 하면서 개발을 하게 됩니다. LOCKED라는 계정의 상태가 데이터베이스에 저장되어 있음을 인지하고 떠올리면서 개발해야하는 것의 차이를 말하고 싶었습니다. ORM을 사용할 때, 도메인 계층에서 영속성을 고려하게 된다 JPA와 같은 ORM..