핵사고날 아키텍쳐는 무엇일까?

김재연·2023년 12월 27일
0

핵사고날 아키텍쳐의 구조 및 정의

출처 : 아마란스의 블로그

핵사고날 아키텍쳐는 다음과 같습니다.

보호받아야 할 도메인 로직이 육각형 내에 있다고 해서 핵사고날 아키텍쳐인 것이죠.

해당 아키텍쳐는 단일 책임 원칙, 의존성 역전 원칙 이 두 가지를 극강으로 활용한 아키텍쳐라고 할 수 있겠네요!

핵사고날 아키텍쳐가 존재하는 이유

소프트웨어는 주기적으로 변경이 필요합니다.

만일 소프트웨어의 의존성이 복잡하게 얽혀 있다면?

기능의 추가나 수정이 있을 때면, 이를 행하기가 굉장히 까다로울 것입니다.

조금의 코드만 고치더라도 고쳐야 할 코드들이 수두룩 할 테니까요.

중요한 이유를 알고, 해결하는 방법을 찾기 이전에 도메인과 인프라 스트럭처의 개념에 대해 확립하고 넘어가야 할 것 같습니다.

도메인은 소프트웨어의 소프트웨어를 통해 이루고자 하는 핵심적인 구성요소를 의미합니다.

즉, 비즈니스 로직이라고 할 수 있겠죠.

인프라 스트럭처는 UI, 외부 API, DB 와 같은 것들을 의미합니다.

비즈니스 로직을 수행해내기 위해서 꼭 필요한 영역들 입니다.

하지만, 우리는 비즈니스 로직에 집중합니다.

진짜배기는 비즈니스 로직에 존재하니까요.

그렇기 때문에 인프라 스트럭처가 변경이 되었을 때, 비즈니스 로직은 영향을 받지 않아야합니다.

그래야지, 최대한 변경사항이 적어지고, 이를 통해 유지보수의 난이도가 낮아질 테니까요.

소프트웨어 아키텍쳐의 목적이 여기서 나옵니다.

소프트웨어를 쉽게 변경할 수 있는 구조로 설계해 유지보수를 쉽게 하기 위함인 것이죠!

어쨌든, 핵사고날은 이를 보장해주기 위한 아키텍쳐이고, 기존 계층형 아키텍처의 한계를 보완하기 위해 나온 개념입니다.

출처 : 아마란스의 블로그

결국 해당 계층형 구조는 영속성 계층에 따라 도메인 계층이, 도메인 계층에 따라 UI 계층이 결정이 될 것입니다.

영속성 -> 도메인 -> 프레젠테이션 계층까지 의존성이 타고 넘어오는 것입니다.

이로 인해 영속성 계층의 변화는 프레젠테이션 계층의 변화로까지 번지게 됩니다.

핵사고날 아키텍쳐는 위 그림과 같은 클린 아키텍쳐를 만족합니다.

위 그림을 간단하게 설명하면 기업의 업무 규칙과 외부 요소를 초록색 부분으로 분리해낸 것입니다.

또한 외부에서 내부의 요소에 단방향으로 의존하도록 하여서, 외부의 변경사항의 내부는 영향을 받지 않습니다.

출처 : 아마란스의 블로그

결국 이렇게 되는 것이죠!

바로 이전 포스트에서 다룬 어댑터 패턴을 활용하여, UI 와 도메인 영역을, 그리고 DB 와 도메인 영역을 연결해주었습니다.

레이어 아키텍쳐랑 다른 점은 영속성 부분도, 어댑터를 활용한 의존성 역전을 이뤄내 도메인을 단방향으로 의존하는 것을 볼 수 있습니다.

이렇게 외부의 변경에 안전한 도메인 설계가 완료되었습니다.

이제 간단하게 실제로 구현해볼까요?

실제로 구현하는 방법

CreateUserUseCase 인터페이스를 통해 비즈니스 로직을 정의하고, 또한 Impl 에서 이를 구현합니다.

또한, UserRepository 인터페이스를 UserRepositoryAdapter 가 구현하여, 외부와의 소통을 담당하게 됩니다.

결론적으로 UI 에서는 CreateUserUseCase 를 통하여 접근할 것이고, DB 에서는 Adapater 를 활용하여 접근할 것입니다.

즉, 도메인 영역이 외부로부터 영향을 받지 않게 된 것입니다.

public interface CreateUserUseCase {

	void createUser(String name, String email);

}

public class CreateUserUseCaseImpl implements CreateUserUseCase {

	private final UserRepository userRepository
	
	public CreateUserUseCaseImpl(UserRepository userRepository) {
		this.userRepository = userRepository;
	}
	
	public void createuser(String name, String email) {
		User user = new User(name, email);
		userRepository.save(user);
	}
}
	
public interface UserRepository {

	void save(User user);

}

public class UserRepositoryAdapter implements UserRepository {

	public void save(User user) {
		// 데이터베이스에 사용자 저장
	}

}

장점 및 단점

  • 장점
  1. 의존성의 방향이 안쪽으로만 향하고 있기 때문에 외부의 변경에 영향을 받지 않는다는 장점이 존재합니다.
  • 단점
  1. 프로그램이 너무 비대해지는 느낌이 있습니다 (이건 제 느낌)

저는 단점보다는 장점이 더 눈에 띄네요.

인프라 스트럭쳐의 변경에 영향을 받지 않는 도메인이라..

환상적인 것 같습니다.

다 같이 한번 도젼해보죠!

참고 자료

https://amaran-th.github.io/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4%20%EC%84%A4%EA%B3%84/Hexagonal%20Architecture(%ED%97%A5%EC%82%AC%EA%B3%A0%EB%82%A0%20%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98)/
https://tech.osci.kr/hexagonal-architecture/

profile
끊임없이 '성장'하는 개발자 김재연입니다.

0개의 댓글