https://refactoring.guru/ko/design-patterns/why-learn-patterns
예비 답안 보기 (👈 Click)
디자인 패턴은 소프트웨어 디자인에서 사용되는 경험적인 패턴들로 이미 검증된 해결책이다.
재사용성, 유연성 등의 장점이 있다고는 하지만 실제로는 공통 언어라는 점이 더 중요하다고 생각한다.
패턴을 알고 있다면 팀원들과 더 효율적으로 의사소통할 수 있고, 코드를 처음 보는 개발자 또한 패턴을 통해 코드를 더욱 쉽게 이해할 수 있다.
예비 답안 보기 (👈 Click)
기존 코드의 재활용과 유연성을 증가시키는 객체 생성 메커니즘
- 팩토리 메서드 패턴 : 부모 클래스에서 객체들을 생성할 수 있는 인터페이스를 제공하지만, 자식 클래스들이 생성될 객체들의 유형을 변경할 수 있도록 하는 생성 패턴
- 추상 팩토리 패턴: 연관성이 있는 객체 군이 여러개 있을 경우 이들을 묶어 추상화하고, 팩토리 객체에서 집합으로 묶은 객체 군을 구현화 하는 생성 패턴
- 빌더 패턴: 상황에 따라 동적인 인자를 필요로 하는 객체를 생성하기 위한 디자인 패턴
- 코틀린에서는 결국 파라미터를 명시하고 값을 주는 것이 빌더 패턴과 유사
- 싱글톤 패턴 : 클래스에 인스턴스가 하나만 있도록 하면서 이 인스턴스에 대한 전역 접근(액세스) 지점을 제공하는 생성 디자인 패턴
- 스프링에서는 빈이 기본적으로 싱글톤으로 관리되며 코틀린에서는 Object 키워드를 통해 싱글톤을 구현할 수 있다.
예비 답안 보기 (👈 Click)
구조를 유연하고 효율적으로 유지하면서 객체와 클래스를 더 큰 구조로 조합하는 방법
- 어댑터 패턴 : 호환되지 않는 인터페이스를 가진 객체들이 협업할 수 있도록 하는 구조적 디자인 패턴
- 파사드 패턴 : 라이브러리에 대한, 프레임워크에 대한 또는 다른 클래스들의 복잡한 집합에 대한 단순화된 인터페이스를 제공하는 구조적 디자인 패턴
- 여러 서비스들을 조합해서 사용할 때 사용했었음.
- 프록시 패턴 : 프록시는 원래 객체에 대한 접근을 제어하므로, 당신의 요청이 원래 객체에 전달되기 전 또는 후에 무언가를 수행하는 패턴
- spring aop가 프록시 패턴을 사용
- 데코레이터 : 새로운 행동들을 특수 래퍼 객체들 내에 넣어서 이러한 행동들을 객체들에 동적으로 추가할 수 있도록 하는 패턴
- 대표적으로 inputStream이 데코레이터 용례로 많이 사용된다.
예비 답안 보기 (👈 Click)
객체 간의 효과적인 의사소통과 책임 할당을 처리
- 전략 패턴: 객체에서 행동의 실행을 연결된 전략 객체에 위임하는 패턴
- 예를 들어, 주문에 다양한 결제 방법이 있다면 order 클래스에 process 메서드에는 payStrategy를 인자로 받아서 대신 처리한다.
- 템플릿 메서드 패턴 : 여러 클래스에서 공통으로 사용하는 메서드를 템플릿화 하여 상위 클래스에서 정의하고, 하위 클래스마다 세부 동작 사항을 다르게 구현하는 패턴
- 옵저버 패턴 : 값을 관찰하여 빠르게 반영하기 위한 디자인 패턴
- spring의 ApplicationEventPublisher가 옵저버 패턴과 같다. 발행하고 구독하는 곳에서 처리
예비 답안 보기 (👈 Click)
헥사고날 아키텍처는 직역하면 육각형 아키텍처이구요. 포트와 어텝터 기반의 아키텍처라고도 합니다. 포트와 어댑터는 인터페이스로 이뤄져있구요. 모든 외부로부터 들어오는 요청은 인바운드 포트로 처리를 하게 되고 외부로 나가는 요청은 아웃바운드 포트로 처리하게 됩니다. 그리고 그 가운데에 도메인 영역이 위치하게 됩니다. 이러한 구조를 헥사고날 아키텍처라고 하구요.
개인적으로 생각하는 헥사고날 아키텍처의 가장 큰 장점은, 포트와 어댑터 인터페이스가 도메인 영역에 위치하기 때문에 SOLID 원칙중에 의존관계 역전 법칙이 구조적으로 적용될 수 있다는 것인데요.
도메인영역은 인터페이스에만 의존하게 되기 때문에 웹계층이나 영속성계층이 어떤 기술로 구현되든지 상관이 없이 느슨한 결합, 확장성있는 구조를 가지게 됩니다. 예를 들어 인프라 영역에 DB 접근 기술로 JPA를 사용하고 있다가 다른 기술로 교체해야하는 시점이 왔을때, 도메인 영역의 코드는 하나도 수정하지 않아도 되는 구조를 가지게 되는 것이 가장 큰 장점이라고 생각합니다.
헥사고날 아키텍처의 가이드 샘플들을 보면 하나의 범용성 service를 쓰는게 아니라 useCase를 쪼개서 각각의 인터페이스를 활용하게 되는데요. 이러다보니 SOLID 원칙 중 단일 책임 원칙, 인터페이스 분리 원칙들을 자연스럽게 지켜나갈 수 있는 구조를 만들어나갈 수 있거든요.
그리고 헥사고날 아키텍처를 사용하다보면 외부 요청은 인바운드로 들어오고 나가는 요청은 아웃바운드 포트로 처리하다보니 그 가운데 있는 도메인 영역을 고도화해서 사용하게 됩니다. 도메인 영역을 고도화해서 사용한다는 측면에서 DDD와도 어느정도 연관이 있게 됩니다. DDD는 도메인의 논리적인 경계인 바운디드 컨텍스트를 기반으로 도메인 간의 명확한 경계를 두고, 분리된 컨텍스트 내에서 비즈니스 요구 사항에 따라 애그리거트를 정의하는 등 비즈니스 도메인에 중점을 두는 설계를 하게 되는데요.
도메인 간의 경계가 명확해짐에 따라 A 도메인의 변화가 B 도메인에 영향을 줘야되는 케이스가 발생했을 때, 느슨한 결합을 유지하면서 처리할 수 있는 EDA 같은 방법론도 적용을 고려해볼 수가 있습니다.
결론적으로, 헥사고날 아키텍처를 도입함으로써 OOP의 SOLID 원칙을 지키면서 시스템의 유연성과 확장성을 높이고, 필요에 따라 다양한 아키텍처적 접근법을 함께 사용할 수 있게 됩니다.