디자인패턴

디자인패턴

 

싱글톤패턴

하나의 인스턴스만 사용되는 경우. 하나의 인스턴스가 사용되지 않는 경우에는 인스턴스의 멤버변수에 저장/입력된 값들이 다른 인스턴스에 공유되지 않는다.  이로인해서 예상한 데이터를 찾을 수 없어서 문제가 발생하기도 함.

빌더패턴

• 장점1 : Setter대신 빌더패턴을 사용하면, 한번 생성된 instance의 값은 변경되지 못하게 하여 thread safe를 확보할 수 있음
• 장점2 : 순차적으로 field를 하나씩 설정할 수 있어서 readbility가 증진됨. 필요한 데이터만 설정할 수 있어서 유연성이 증가됨
• 장점3 : 필요한 데이터만 설정할 수 있어서 유연성이 증가됨

스태틱팩토리패턴

 

 

프록시패턴

프록시 패턴의 핵심은 바로 인터페이스의 동일성을 유지함으로써, 클라이언트가 실제로 대리 객체를 사용하고 있는지, 아니면 실제 객체를 사용하고 있는지 신경 쓸 필요가 없도록 만드는 데 있습니다.  서버는 대리객체를 통해서 원래 객체를 호출하고 추가적인 로직을 실행한다.

프록시의 장점은 원래 실제 객체에 기능을 추가하거나 변경하지 않고도, 그 객체에 대한 접근 방식이나 동작을 확장할 수 있게 만드는 것입니다.

 

• 접근 제어: 프록시는 원래 객체에 대한 접근을 제어할 수 있습니다. 예를 들어, 특정 조건에서만 실제 객체에 접근하도록 하거나, 접근 전에 인증 및 권한 검사를 수행할 수 있습니다.
• 기능 확장: 프록시는 원래 객체의 메서드를 호출하면서 추가적인 기능(예: 로깅, 트랜잭션 관리, 성능 모니터링 등)을 수행할 수 있습니다.
• 지연 초기화(Lazy Initialization): 프록시를 사용하면 실제 객체를 필요한 시점까지 생성하지 않고 미뤄둘 수 있습니다.

 

오케스트레이션 패턴 (Orchestration Pattern)

오케스트레이션 패턴은 여러 개의 서비스나 컴포넌트가 연동하여 특정 비즈니스 로직이나 워크플로우를 수행할 때 사용됩니다. 이 패턴에서는 하나의 **오케스트레이터(조정자)**가 전체 흐름을 책임지고, 각 서비스 간의 작업 순서와 상호작용을 명확히 관리합니다.

• 오케스트레이터는 각 작업을 적절한 순서로 호출하여 최종 목표를 달성합니다. 이를 통해 각 서비스는 독립적으로 자신의 역할을 수행하고, 오케스트레이터가 이를 하나로 묶어 비즈니스 프로세스를 완성합니다.
• 예를 들어, 고객 주문 프로세스를 생각해볼 수 있습니다. 고객의 주문을 처리하기 위해 여러 단계(고객 정보 확인, 재고 확인, 결제 처리, 배송 요청 등)가 필요한데, 오케스트레이터는 각 단계를 순차적으로 관리하며 필요한 서비스를 호출하고, 다음 단계로 넘깁니다.

오케스트레이션의 장점은 시스템이 모듈화되고, 비즈니스 로직이 명확하게 중앙에서 관리된다는 점입니다. 이를 통해 변경사항이 생길 때 특정 서비스의 내부 로직을 수정하지 않고 오케스트레이터에서 조정할 수 있습니다.

 

퍼사드 패턴 (Facade Pattern)

퍼사드 패턴은 시스템의 복잡성을 숨기고 단순한 인터페이스를 제공하여 클라이언트가 시스템과 상호작용하기 쉽게 만드는 데 사용됩니다. 여러 개의 복잡한 서브시스템이나 서비스가 존재할 때, 퍼사드는 그 모든 기능을 감싸서 하나의 간단한 인터페이스를 제공합니다.

• 예를 들어, 어떤 소프트웨어 시스템이 여러 개의 모듈(결제 모듈, 사용자 관리 모듈, 알림 모듈 등)을 포함하고 있다면, 퍼사드는 이러한 모듈들의 복잡한 API를 숨기고, 하나의 단순한 메서드 호출로 모든 작업을 수행할 수 있게 만들어줍니다.
• 이를 통해 클라이언트는 내부 시스템의 복잡한 구성 요소를 알 필요 없이 단순히 퍼사드를 호출하여 작업을 완료할 수 있습니다.

퍼사드 패턴의 장점은 사용의 용이성과 내부 구현의 캡슐화입니다. 클라이언트는 시스템의 복잡한 내부 구현을 알 필요 없이 간단한 인터페이스만 사용하여 기능을 이용할 수 있습니다.

 

디자인원칙

계층분리 : 계층은 관심사에 따라 분리되어 있으며, 직접적으로 맞닿은 계층이 아니면 의존관계가 없기 떄문에, 테스트 환경을 구성할 때, 그 계층의 환경만 고려.

Clean Architecture Principles

  dependencies should always point inward—toward the higher-level, more abstract layers of the system (like Entities and Use Cases, most generalized, least dependent on specific details, and most central to the business logic), and never outward toward lower-level, concrete implementations (like Frameworks, Drivers, and UI). The idea is to keep the core business logic (Entities and Use Cases) isolated from external concerns like UI, databases, or external APIs.

  컨트롤러나 인터페이스 어뎁터는 외부의 시스템과 접촉하면서 내부 로직에 필요한 데이터만 순수하게 빼내는 로직들이 존재하는 곳이다. 클라이언트 측과 접촉하는 컨트롤러/필터나 외부라이브러리와 접촉하는 어뎁터는 외부세계를 중개한다는 측면에서는 동일한 계측인 것이다.

  Seperation of Concerns을 위해서 Dependency가 안쪽으로 이어진다는 뜻이지 Layer간 Dependency가 존재하지 않는다는 뜻은 아님. 통신을 담당하는 Filter의 logic을 process하기 위해서 Interface Adapter를 사용할 수 있다는 것. 반면 Interface Adapter에서 Filter을 의존해서는 안되는 것임. 

• Entities
  • 엔티티는 소프트웨어에서 문제 해결을 위해 핵심이 되는 업무 규칙들이 속하는 계층으로, 도메인이라고 할 수 있다.
  • 엔티티는 단순히 속성들로만 구성된 객체일수도, 속성과 메소드로 구성된 객체일 수 있다.
  • 엔티티 계층은 프레임워크, DB 등 어플리케이션을 구성하는 그 어떤 것들도 영향을 미쳐서는 안된다. 즉, 다른 계층들로부터 보호되어야 하는 계층이다.
• Usecase
  • 유즈케이스는 어플리케이션 수준의 업무 규칙들이 속하는 계층이다.
  • 유즈케이스는 어플리케이션 상에서 엔티티 간 데이터 통신을 관장하고, 또한 엔티티의 업무 규칙들이 어플리케이이션 상황에서 실행되도록 하는 코드들이 포함된다.
  • 유즈케이스는 엔티티와 마찬가지로 어플리케이션을 구성하는 외형적인 특징들, DB, 프레임워크 등에 영향을 받아서는 안된다. 
• Interface adapter
  • 인터페이스 어댑터는 외부에서 유입되는 데이터를 유즈케이스와 엔티티에서 사용하기 편한 방식으로, 또 반대 방식으로 데이터를 변환하는 것을 담당하는 계층이다.
  • 계층형 아키텍처에서 presentation에 속하는 controller와 같은 것이 이 계층에 속할 수 있다.
  • Controller : The controller can indeed call service logic and other interface adapter logic to orchestrate the request handling process. keep its focus on routing, delegating, and response construction.
• Frameworks and drivers
  • 소프트웨어를 구성하는 세부 사항에 해당한다. technical details and external systems을 담당한다.
  • 소프트웨어에서 사용하는 프레임워크, 데이터베이스, 웹/앱 인터페이스가 이에 해당한다.
  • 외부통신과의 스프링 Config, filter,