왜 Architecture를 고민해야하는가?

• SW 를 만들고 우지보수를 위한 자원(인력 시간 등) 을 최소화 하기위해
• 구현을 우선하고 구조의 최적화? 높은확률로 불가능하다
• Architecture : 개발의 필요한 구성요소들을 어떤 구조로 배치할 것인가?
  • 해당 주제는 Spring Boot App 에서의 구조! (3-Layered, 4-Layered 등)

어떤 Architecture가 좋은가?

• 절대적인 정답은 없다! 나의 상황에서 가장 적합한 구조를 사용하자.

• 동일한 구조를 사용해도 디테일적으로는 전부 다르다.

  • 각각의 Architecture가 추구하는 본질은 다르고 파생되는 특징, 장점을 깨달아야 나에게 맞는 적합한 Architecture를 만들 수 있다.
    

• 3-Layered : C/S/A 3개의 계층으로 나뉘어지는 구조.

  • 각 계층의 책임이 명확하고 구현 난이도가 낮다.
  • Service 에 많은 코드가 들어갈수 밖에 없는 구조라 규모가 커질수록 사용이 힘들다.
  • 계층의 역할이 너무 구체적이라 어느 계층에 위치해야할지 정하기 어렵다.
    

• 4-Layered : 4개의 계층으로 나누어지는 계층

  • 계층을 세분화 하고 추상화하여 단점의 보완.

  • Domain 계층의 분리로 DDD 에서 설명되는 개념을 구현하기 쉽다.

    

• Hexagonal : 내부/외부 영역을 분리, 이후 Port/Adaptor 를 이용하여 엄격한 의존성관리.

  • 내부/외부를 엄격하게 격리시켜 변경으로부터의 보호성이 강하다.

의존성 규칙

• 의존성은 항상 변경을 전파한다. 따라서 저수준 -> 고수준 의 방향을 만들어야한다. (컴파일 의존성)
• 모든 Architecture는 의존성 규칙 만큼은 지키고 있다.

DIP 의존성 역전의 원칙

• 만약 고수준 -> 저수준 의 방향이라면 DIP를 활용해 방향을 바꿔줄 수 있다. 해당 방법을 이용하면 의존성 규칙을 100% 지킬수 있음.
• 의존성 규칙 을 지키기 위해 의존성 방향을 뒤집을 수 있다.

Clean Architecture

• Domain Entity : 회사차원에서의 핵심 업무규칙

  • 매우 고수준의 모듈, 규칙에 의해 다른 모듈을 의존하지 않는다.
  • 핵심업무에 필요한 데이터가 함께 결합되어 있다.

• UseCase : 요구사항, 비즈니스 로직

  • 특정 APP 에 특화된 업무규칙(비즈니스 로직)을 뜻함.
  • 업무규칙 절차 설명
  • 구체적인 업무규칙은 Entity에게 위임
  • 요청/응답 데이터는 간단한 형태여야 한다.

• 특정목적을 이루기 위해 규칙 및 절차를 설명하고, 과정에서 어떤 Entity가 동작해야하는지 호출하고 위임한다.

• Domain Logic Vs Business Logic

  • Domain Logic : 비즈니스에서 중요한 결정을 내리는 로직
    • Domain 모델에게 행위를 위임함으로써 모델이 스스로 문제를 해결해야 한다.
    • Domain 은 응집도가 올라가고 Business 는 설명적 형태를 얻는다

Hexagonal Architecture는 Clean Architecture ?

• 중심은 Domain/Business 가 존재하고 모든의존성은 밖에서 들어온다.

Hexagonal Architecture 맛보기

• 순수한 DomainEntity 와 JPA Entity 를 분리 할 필요가 있다.
  • Domain Entity 가 외부로 의존성관계가 생기게 되버림! (순수한 JAVA 객체)

• 기존의 interface 를 이용한 다형성의 구조라고 보면 이해가 쉬울거 같다!
• 내부영역은 외부의존성이 아예 존재하지 않지만 Port/Adator 를 통해서 외부영역의 필요한 DB 객체 (JPA , JDBC) 등으로 변경이 가능하다.
• 멤버와 멤버레파지토리는 외부의 변경에서 매우 안전하다!
• 가장 눈에보이는 명확한단점은 생산성의 악화가 크다.

추가사항

• 멀티모듈의 확장성을 항상 고려하자. 규모가 커질수록 서버는 늘어날수 밖에없다.
  

• 패키징 구조를 고려하여 설계를 하는 관점을 길러보자