1장 2장 3장

[kihyuk-sung]

~ 32p 까지

[kihyuk-sung]

01. 계층형 아키텍처의 문제는 무엇일까?

• 계층을 잘 이해하고 구성하면 좋은 아키텍처를 만들 수 있다.
• 나쁜 습관이 스며들기 쉽게 만들고, 소프트웨어를 점점 더 변경하기 어렵게 만드는 수많은 허점들을 노출한다.

문제점의 이유

1. 의존성의 방향에 따라 데이터베이스 주도 설계를 유도한다.
2. 제약이 적어 지름길을 택하기 쉬워진다.
3. 지름길을 택하다보면 테스트하기 어려워진다.
4. 도메인 서비스의 너비에 대한 규칙을 강제하지 않아 유스케이스를 숨긴다.
5. 동시 작업이 어려워진다.
   • 데이터베이스 주도 설계를 한다면 레이어 별로 작업하기 어렵다.
   • 코드에 넓은 서비스가 있다면 서로 다른 기능을 동시에 작업하기 어렵다.

02. 의존성 역전하기

단일 책임 원칙

컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다.

의존성 역전 원칙

코드상의 어떤 의존성이든 그 방향을 바꿀 수 있다.

클린 아키텍처

• 계층 간의 모든 의존성이 안쪽으로 향해야 한다.
• 유스케이스로 넓은 서비스 문제를 피한다.
• 다만 애플리케이션의 엔티티에 대한 모델을 각 계층에서 유지보수해야 한다.
• 육각형 아키텍처 (헥사고날 아키텍처, ports and adapters 아키텍처)

결론

• 도메인 로직의 결합을 제거하고, 변경할 이유의 수를 줄인다.

03. 코드 구성하기

1. 계층으로 구성하기
2. 기능으로 구성하기
3. 육각형 아키텍처에서 사용하는 요소들을 이용한 패키지 구성

   buckpal
   |----account
      |------in
      |          |----web
      |                   |----------AccountController
      |------out
      |          |----persistence
      |                   |-----------AccountPersistenceAdapter
      |                   |-----------SpringDataAccountRepository
      |
      |------domain
      |         |----Account
      |         |----Activity
      |
      |------application
                |----SendMoneyService
                |
                |----port
                       |----in
                       |       |----SendMoneyUseCase
                       |
                       |----out
                               |----LoadAccountPort
                               |----LoadAccountPort

의존성 주입의 역할

• 애플리케이션 계층이 인커밍/아웃고잉 어댑터에 의존성을 갖지 않는 것이다.
• 모든 계층에 의존성을 가진 중립적인 컴포넌트 하나를 도입한다. (IoC Container)

[polynomeer]

계층형 아키텍처의 문제는 무엇일까?

• 웹 계층이나 영속성 계층에 독립적으로 도메인 로직을 구성한다면 견고한 아키텍처
• 계층을 적절하지 않게 구성하고, 의존이 강해져서 종종 변경이 어렵게 됨

계층형 아키텍처는 데이터베이스 주도 설계를 유도한다

계층형 아키텍처의 토대는 데이터베이스인데, 웹 계층 -> 도메인 계층 -> 영속성 계층에 의존하면서 데이터베이스에 의존하게 된다.

비즈니스는 상태가 아니라 행동을 중심으로 모델링 하지만, 아키텍처는 도메인 로직이 아닌 데이터베이스를 토대로 설계하게 된다. 이는 ORM 사용 시 특히 두드러진다. 특히 영속성 계층과 도메인 계층의 결합이 발생하게 된다.

지름길을 택하기 쉬워진다

헬퍼, 유틸리티, 레포지토리 컴포넌트들을 영속성 계층으로 모두 끌어내릴 가능성이 커진다.

테스트하기 어려워진다

• 도메인 로직을 웹 계층에서 구현하게 된다.
• 웹 계층 테스트에서 도메인 계층, 영속성 계층까지 모킹해야 한다.

유스케이스를 숨긴다

레거시에 새로운 기능을 추가할 때 어디에 추가할 지 몰라서 가장 편한 곳에 추가하게 된다. 그러면 유스케이스를 찾기가 어려워진다. 즉, 서비스 클래스가 엄청 비대해질 수 있다.

동시 작업이 어려워진다

서로 다른 기능을 동시에 작업하기 어렵다. 예를 들어, 사용자 서비스를 만들기 위해서 한 명이 엔티티와 레파지토리 등 틀을 어느정도 잡아주면 그에 종속되어서 개발할 수 밖에 없다. 이때 맨먼스는 당연히 의미가 없어진다.

유지보수 가능한 소프트웨어를 만드는 데 어떻게 도움이 될까?

계층형 아키텍처도 올바르게 구축하면 쓸만하다.

---

의존성 역전하기

단일 책임 원칙

컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다.

'책임'은 '변경할 이유'에 대응된다. 하나의 변경사항에 대해서 적용할 때 하나의 컴포넌트만 변경하면 되도록 잘 쪼개어서 설계해야한다.

의존성 역전 원칙

코드상의 어떤 의존성이든 그 방향을 바꿀 수(역전시킬 수) 있다.

클린 아키텍처

도메인 계층이 영속성이나 UI같은 외부 계층과 철저하게 분리돼야 하므로 애플리케이션의 엔티티에 대한 모델을 각 계층에서 유지보수해야 한다. 가령 ORM을 사용할 때, 영속성 계층의 엔티티가 도메인 계층에도 별도로 존재해야 한다.

헥사고날 아키텍처

포트와 어댑터 아키텍처

[jihye-woo]

계층형 아키텍처의 한계

1. 도메인이 아닌 데이터베이스 모델을 기반으로 코드를 작성하게 됨

• 특히 계층형 아키텍처 + ORM = 도메인 로직 + 영속성 관련 코드가 혼재하기 쉬운 환경이 됨
  • 왜? 도메인 계층에서 영속성 레이어의 엔티티를 사용해야하기 때문
  • 즉, 도메인 계층이 영속성 레이어에 대한 종속성이 생기면서 강결합 발생

    2. 테스트 힘들어짐

  • 이 부분은 웹 계층에 도메인 로직이 들어있을 때 한정한 경우 아닌가
  • 보통은 도메인 레이어에만 도메인 로직이 들어가도록 구현하므로 그다지 공감되진 않았음

    3. usecase를 숨긴다 (+ 뚱뚱한 서비스 클래스)

  • 여러 개의 유스 케이스를 담당하는 하나의 큰 서비스가 등장할 수도 있다
  • 일반적인 계층형 아키텍처에서는 서비스의 '너비'에 대한 제약이 없기 때문
  • (-> 서비스 로직이 여러 도메인에 걸쳐있는 경우, 나는 해당 서비스들을 묶어주는 하나의 큰 서비스(AggregateService)를 앞단에 두고서 최대한 쪼개려고 한다 [aggregate pattern 참고]

의존성 역전하기

1. 단일 책임 원칙

• 컴포넌트를 변경하는 이유는 오직 하나 여야 한다
• BUT 컴포넌트 간의 의존성이 있다면, 변경하는 이유는 쉽게 전파된다(부수효과)

  2. 의존성 역전의 원칙

  • 코드 상의 어떤 의존성이든 그 방향을 역전시킬 수 있어야 한다
    • 이의 대표적인 예시
    • 도메인 레이어의 서비스 구현체가 영속성 레이어의 레포지토리 구현체를 직접 의존하는 형태가 아니라 (도메인 -> 영속성)
    • 도메인 레이어에서 레포지토리의 인터페이스를 가지고 있고, 영속성 레이어의 실제 레포지토리 구현체가 해당 인터페이스에 의존하는 형태로 변경하여 의존성 역전을 달성 (도메인 <- 영속성)
• 상위 계층들이 하위 계층들에 비해서 변경할 일이 많다
• 즉, 의존성 이슈로 영속성 레이어의 코드 변경에 따라 도메인 레이어의 코드도 함께 변경해야할 일이 반대의 경우보다 상대적으로 많다는 뜻

3. 클린 아키텍처

• 자료 출처 : https://www.freecodecamp.org/news/a-quick-introduction-to-clean-architecture-990c014448d2/
  • 계층 간의 모든 의존성 방향은 안쪽으로 향함
  • 단일 책임을 달성하기 위해, 서비스들이 유스케이스 단위로 더 잘게 쪼개져 있다
  • 도메인 계층이 외부와 철저히 분리되어있어야 하므로, 각 계층에서 어플리케이션에 대한 모델을 관리해야 함
  • 책에서는 계층간 결합이 제거된 상태로 만들기 때문에, 맞다고하지만 나는 살짝 다른 생각
  • 모델이 분산되고, 모델에서 하나가 변경된다면 다른 레이어의 모델에도 반영해주어야 한다는 단점이 있을 듯 하다
  • 코드양도 늘어나게될 것 같다

4. 헥사고날(육각형) 아키텍처

• 포트와 어댑터 아키택처라고도 함
• Driving Side vs Driven Side
• 잘 설명해주고 있는 사이트 같은데 졸려서 정독은 못하고 일단 링크만 걸어둡니다

_코드 구성하기

계층으로 구성하기

• web / domain / persistence
  • 호출 방향 및 의존성이 패키지 구조로는 명확히 보이지 않는다
  • 영속성 어댑터가 도메인에게 어떤 기능을 제공하는지 안보임
  • in 혹은 out 포트가 명확히 보이지 않는다

    기능으로 구성하기

• 예를 들어, 계좌와 관련된 유스케이스라면 account 라는 패키지 아래 모든 레이어 영역의 코드를 넣는 구조
• 기반 아키텍처가 패키지 구조를 통해서 명확히 나타나지 않는다

  아키텍처구조가 반영된 패키지 구조

• 패키지 구조가 아키텍처를 반영할 수 없게되면 유지보수 과정에서 점점 기존의 아키텍처 구조에서 멀어지게 된다

의존성 주입의 역할

• 어플리케이션 계층이 인커밍/아웃커밍 어댑터에 의존성을 갖지 않아야 함
  • 인커밍 -> 어플리케이션 : 로직 제어 흐름과 의존성 방향이 일치하므로, 인커밍쪽에서 어플리케이션 계층의 서비스를 호출해주면 됨
  • 아웃커밍 -> 어플리케이션 : 로직 제어 흐름에 역행하는 쪽으로 의존성 방향이 나와야 함 -> 이때 의존성 역전을 사용
  • 원래 앞선 의존성 역전 예시에서는 interface 정의를 통해 달성했지만, 어플리케이션 레이어에서 의존성 주입을 통해서 달성할 수도 있다

[kyupid]

01. 계층형 아키텍쳐의 문제점은 무엇일까?

• 계층형 아키텍쳐는 코드에 나쁜 습관들이 스며들기 쉽게 만들고 시간이 지날수록 소프트웨어를 점점 더 변경하기 어렵게 만드는 수많은 허점들을 노출한다.

계층형 아키텍쳐는 데이터베이스 주도 설계를 유도한다.

• 이렇게 만드는 주원인은 ORM
• 데이터베이스 주도 설계가 나쁜 이유는?
  • 영속성 코드가 도메인 코드에 녹아들어가서 둘 중 하나만 바꾸기가 어려워 진다.
  • 영속성 코드라 하면, 즉시로딩/지연로, 트랜잭션, 플러시 등 영속 계층과 관련된 작업들

지름길을 택하기 쉬워진다.

• 계층형 아키텍쳐는 어떤 컴포넌트가 있어야 할 곳에 두지 않고 다른 계층에 둘 유혹에 빠지기 쉽다

테스트하기 어려워진다.

• 지름길을 택하면서 간단한 엔티티 필드 하나 조작하는 것 등을 컨트롤러에서 한다면 웹 계층 테스트에서 도메인 계층 뿐만아니라 영속성 계층도 모킹해야한다.
• 즉, 테스트의 복잡도가 올라간다

유스케이스를 숨긴다

• 계층형 아키텍쳐에서는 도메인 로직이 흩어질 가능성이 높다
• 한 서비스에 다 때려박으면 서비스가 너무 두꺼워진다(넓어진다).

동시 작업이 어려워진다

• 여러 사람이 동시 작업할때 계층형 아키텍쳐가 그닥 도움이 되지 않는다.

유지보수 가능한 소프트웨러를 만드는 데 어떻게 도움이 될까?

• x

02. 의존성 역전하기

• 계층형 아키텍쳐의 대안에 대해 이야기해보자

단일 책임 원칙

• "오로지 한가지 일을 하는 것"이 아니라 "오로지 변경할 이유가 하나"로 기억해라

Q1. 이해 안가는점

• 컴포넌트가 변경할 이유가 하나라면 어떤 다른 이유로 소프트웨어를 변경하더라도 이 컴포넌트에 신경쓸 필요가 없다는말이 무슨 말일까요?
  • 변경할 이유가 하나인데 다른 이유로 소프트웨어를 변경한다는 말이 무슨 말인지 잘 모르겠습니다
• 그림 2.1은 무엇을 설명하는 것일까요?
  • A는 변경할 이유가 두가지 이고 단일 책임원칙을 지켰지 않았다는 것이고, 이것을 문제라고 말하는 것 같은데 왜 문제인지 잘 이해가 가지 않아요

부수효과에 관한 이야기

• x

의존성 역전 원칙

• Q2. 단일 책임 원칙을 고수준에서 적용한다?
  • 고수준이라 함은 웹계층을 말하는 것일까요?
• 계층형 아키텍쳐에서 영속계층과 도메인게층을 분리하려면 DIP를 적용해야한다.
• DIP: 코드상의 어떤 의존성이든 그 방향을 바꿀 수(역전시킬 수) 있다. (양쪽 코드를 모두 제어할 수 있을 때)
• Q3. 엔티티랑 ORM-Managed 엔티티는..실제 코드상에서 어떤걸 말하는 것일까요..?

클린 아키텍쳐

• Q4. 계층 분리로 인해 애플리케이션 엔티에 대한 모델ㄹ을 각 계층에서 유지보수해야한다는 게 뭐가 문제일까요?
• Q3이랑 같은 이야기이지만 계층형 문제를 피하기 위해서 이런식으로 두 엔티티를 만드는 아키텍쳐는 어떤 모양일까 궁금하다.
  • 영속계층에 있는 리포지토리에서 엔티티 어노테이션으로 매핑되어있는 도메인에 있는 객체를 사용할때 JPA에서 내부적으로 뭔가 만드는 것이기 때문에 추상화되어서 안보이는 것인가?

유지보수 가능한 소프트웨러를 만드는 데 어떻게 도움이 될까?

• 도메인, 영속 게층간의 결합을 제거하고 코드를 변경할 이유의 수를 줄일 수있고, 이때문에 유지보수성은 더 좋아진다.
• 비즈니스코드 영속코드 ui 코드는 각각 자유롭게 모델링 될수있다

03. 코드 구성하기

계층으로 구성하기

• 24p
• 기능 조각이나 특성을 구분짓는 패키지경계가 없어 좋지않다
• 유스케이스 파악이 힘들다. AccountService가 무슨 일을 하는 것인가?

기능으로 구성하기

• 25p
• 코드구성하는 기반 아키텍쳐가 아예 보이지 않는다

... ... ... Q1. 컴포넌트를 변경할 이유가 하나라면 다른 컴포넌트를 수정한다고 영향이 가지 않는다는 그런 이야기의 번역체

Q3. WritingEntity CommentingEntity

domain ExampleEntity WritingEntity

persistence @Entity ExampleEntity

---

domain CommentingEntity

[janeljs]

01 계층형 아키텍처의 문제

계층형 아키텍처

웹 > 도메인 > 영속성

계층형 아키텍처는 데이터베이스 설계를 유도한다.

• 웹 > 도메인, 도메인 > 영속성 계층에 의존하기 때문 → 결국 데이터베이스에 의존적
• ORM 프레임워크 사용 → 도메인 계층(서비스)에서 데이터베이스 엔티티를 사용 → 비즈니스 로직과 영속성 계층과의 결합도 증가
• 도메인 로직 외 즉시로딩, 지연로딩, 데이터베이스 트랜젝션, 캐시 플러시 등의 작업을 해야함

지름길을 택하기 쉬워진다.

• 상위 컴포넌트에 접근하고 싶다고 상위 컴포넌트를 자꾸 내리다보면 영속성 계층이 비대해짐
  • 헬퍼나 유틸리티 컴포넌트가 영속성 계층으로 내려옴(리포지토리 사용)

테스트하기 어려워진다.

• 웹 계층에서 영속성 계층으로 직접 접근한다면 도메인 로직이 웹 계층에 추가되게 되고 핵심 도메인 로직이 분산됨
• 웹 계층 테스트에서 도메인 계층 + 영속성 계층까지 mocking해야 함

유스케이스를 숨긴다.

• 한 개의 서비스가 여러개의 유스케이스를 담당하게 되면서 서비스 테스트가 어려워진다.
• 특정 유스케이스를 담당하는 서비스 찾기가 어려워진다.

동시 작업이 어려워진다.

• 계층형 아키텍처는 동시 작업을 진행하기 어렵다.
• 비대한 서비스가 있다면 충돌이 일어날 확률도 높고, 데이터베이스 주도 설계를 하는 경우가 많기 때문

02 의존성 역전하기

단일 책임 원칙

• 컴포넌트를 변경하는 이유가 한 가지 뿐이라는 것 = 다른 이유로 변경이 발생했을 때 다른 컴포넌트의 변경에 신경쓸 필요가 없다는 것
• 실상은 transitive dependency를 가지고 있음

의존성 역전 원칙

• 코드상의 어떤 의존성이든 그 방향을 역전시킬 수 있다는 것
• 도메인 계층이 영속성 계층에 의존하던 것을 영속성 계층이 도메인 계층에 의존하는 형태로 바꿔보자
• 도메인 계층에 repository interface를 도입해서 영속성에 있는 구현체가 도메인 계층을 바라보게 하기

클린 아키텍처

• 도메인 코드가 바깥으로 향하는 코드에 대해 어떤 의존성도 없어야 한다.
• JPA로 엔티티에 기본 생성자가 추가되는 것 - 도메인 계층과 영속성 계층의 결합
  • 도메인과 영속성 계층의 엔티티를 각각 생성하면 결합이 끊어짐
  • But, 계층별로 변환해야함

헥사고날 아키텍처

출처: https://reflectoring.io/spring-hexagonal/

03 코드 구성하기

패키지 구조

• 최상단 패키지의 이름은 기능이 드러나게 하자
• screaming architecture
• incoming port와 outgoing port, 아키텍처가 패키지 레벨에서부터 보이게 하자

의존성 주입의 역할

• 모든 계층에 의존성을 가진 중립적인 컴포넌트 도입
• Account Persistence Adapter처럼 outgoing adapter의 경우에는 DIP 적용이 필요함
• Port 인터페이스를 둬서 서비스는 포트만 호출하면 되도록, 의존성 주입으로 인스턴스 받아오기