From d8d798266f8a1ed1ec50024a4616589114f5950c Mon Sep 17 00:00:00 2001 From: kwanguuuu Date: Mon, 3 Jan 2022 10:26:36 +0900 Subject: [PATCH] =?UTF-8?q?docs:=20=EC=B1=95=ED=84=B001=EC=A0=95=EB=A6=AC?= =?UTF-8?q?=20(=20=EA=B3=84=EC=B8=B5=ED=98=95=20=EC=95=84=ED=82=A4?= =?UTF-8?q?=ED=85=8D=EC=B2=98=EC=9D=98=20=EB=AC=B8=EC=A0=9C=EB=8A=94=20?= =?UTF-8?q?=EB=AC=B4=EC=97=88=EC=9D=BC=EA=B9=8C=20)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...64\354\227\207\354\235\274\352\271\214.md" | 74 +++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 "docs/01_\352\263\204\354\270\265\355\225\234_\354\225\204\355\202\244\355\205\215\354\262\230\354\235\230_\353\254\270\354\240\234\353\212\224_\353\254\264\354\227\207\354\235\274\352\271\214.md" diff --git "a/docs/01_\352\263\204\354\270\265\355\225\234_\354\225\204\355\202\244\355\205\215\354\262\230\354\235\230_\353\254\270\354\240\234\353\212\224_\353\254\264\354\227\207\354\235\274\352\271\214.md" "b/docs/01_\352\263\204\354\270\265\355\225\234_\354\225\204\355\202\244\355\205\215\354\262\230\354\235\230_\353\254\270\354\240\234\353\212\224_\353\254\264\354\227\207\354\235\274\352\271\214.md" new file mode 100644 index 0000000..cecbb78 --- /dev/null +++ "b/docs/01_\352\263\204\354\270\265\355\225\234_\354\225\204\355\202\244\355\205\215\354\262\230\354\235\230_\353\254\270\354\240\234\353\212\224_\353\254\264\354\227\207\354\235\274\352\271\214.md" @@ -0,0 +1,74 @@ +# 01. 계층형 아키텍처의 문제는 무엇일까? + +### TL;DR +계층형 아키텍처는 시간이 지날수록 소프트웨어를 변경하기 어렵게 만드는 허점을 노출한다 +- [ ] 계층형 아키텍처는 데이터베이스 주도 설계를 유도한다. +- [ ] 지름길을 택하기 쉬워진다. +- [ ] 테스트 하기 어려워 진다. +- [ ] 유스케이스를 숨긴다. +- [ ] 동시작업이 어려워 진다. + + +### 계층형 아키텍처 +- 전통적인 웹 어플리케이션 구조 +- 웹계층, 도메인계층, 영속성 계층으로 구성됨. (3 layer architecture) + - 웹계층: 요청을 받는다. 받은 요청을 도메인 계층으로 전달한다. + - 도메인(비즈니스) : 필요한 비즈니스 로직을 수행한다. 영속성계층을 호출한다. + - 영속성계층: 도메인 엔티티의 상태를 조회하거나, 변경하기 위해 영속계층의 컴포넌트를 호출한다. +- 대부분의 웹서비스가 3 레이어의 계층형 아키텍처가 많을듯. +- 계층형 아키텍쳐는 견고한 아키텍처 패턴이다. 계층을 잘 구성했다면, 웹계층&영속성 계층에 독립적으로 도메인 로직을 작성할 수 있다. +- 로버트 마틴(엉클밥)이 말하는 클린 아키텍처의 전부는, **선택의 폭을 넓히고 변화하는 요구사항과 외부 요인에 빠르게 적응할 수 있게 하는 아키텍쳐를 말한다.** + 그리고 이는 계층형 아키텍처로도 구현할 수 있다. +--- +**계층형 아키텍처의 문제점?** +- (경험) 코드에 나쁜 습관이 스며들기 쉽게 만들고 시간이 지날수록 소프트웨어를 점점 변경하기 어렵게 만드는 **허점을 노출한다.** + +### 계층형 아키텍처는 데이터베이스 주도 설계를 유도한다. +- 전통적인 계층형 아키텍처의 토대는 데이터베이스다. +- 웹> 도메인 > 영속성 으로 이어지는 구조는 자연스럽게 데이터 베이스에 의존한다. +- 비즈니스가 상태가 아닌 행동을 중심으로 모델링을 한다. + +왜 데이터베이스를 토대로 아키텍처를 만드는 걸까? +- 유스케이스 떠올려보면, 대부분 데이터모델링(영속성계층생각)후 도메인 로직을 구현한다. +- 이런 방법이 계층형 아키텍쳐에서는 합리적인데, 비즈니스 관점에서는 맞지 않는 방법이다. +- 도메인 로직을 먼저 만들어야. 로직을 제대로 이해 했는지 확인할 수 있다. 그리고 이를 기반으로 영속성계층과 웹 계층을 만들어야 한다. + +데이터중심의 아키텍쳐가 만들어 지는 원인은 ORM 때문이다. +- ORM을 계층형 아키텍쳐와 조합해보면, 비즈니스 규칙을 영속성 관점과 섞고싶은 유혹을 쉽게 받는다. +- 엔티티는 일반적으로 영속성 계층인데, 도메인 계층에서 쉽게 접근할 수 있다. 그리고 이런 점으로 인해 사용되기 마련이다. + - 이는 도메인&영속성 계층의 강결합을 만든다. + - 서비스가 영속성 모델을 비즈니스 모델처럼 사용하게 되고, 도메인 로직 뿐 아니라 영속성 계층과 관련된 작업들을 해야한다 + - 영속성 관련 작업 : eager loading, lazy loading, trancsaction, cache, flush .. +- 영속성 코드가 도메인에 녹아들면, 둘중 하나만 바꾸는 것이 어려워 진다. + +### 지름길을 택하기 쉬워진다. +`지름길모드`: 상위 레이어의 컴포넌트를 하위 레이어로 내리는 행위 + +전통적인 아키텍처 모두에 적용되는 유일한 규칙은, 특정한 계층에서는 같은 계층에 있는 컴포넌트나 아래에 있는 계층에만 접근가능하다는 것이다. + +그래서 상위 계층에 위치한 컴포넌트에 접근해야 한다면, 컴포넌트를 아래 계층으로 이동시키면 된다. + +영속성 계층은 시간이 지날 수록 비대해진다. **헬퍼, 유틸리티 컴포넌트들이 아래 계층으로 내려가기 쉬운 가능성 큰 후보다** + +아키텍처 `지름길모드`를 종료하고 싶다면, 추가적인 규칙을 강제해야한다. ( 빌드 실패 등..) + +### 테스트하기 어려워진다. +종종 나오는 변화의 행위는 `계층을 건너 뛰는것이다.` + +위의 문제는 +1. 도메인 로직을 웹 계층에 구현하게 되는 것이다. 이는 책임이 섞이고 핵심 로직이 퍼져나갈 확률이 높다. +2. 웹 계층에서 영속성 계층도 모킹해야 한다는 것이다. 단위 테스트의 복잡도가 올라가고, 테스트 설정이 어려워진다. 테스트설정이 어렵다는 것은 테스트를 작성하지 않는 방향으로 가는 것이다. + +### 유스케이스를 숨긴다. +아키텍처는 코드를 빠르게 탐색하는데 도움이 돼야 한다. + +계층형 아키텍쳐에서는 도메인 로직이 여러 계층에 흩어지기 쉽다. 그래서 적당한 코드를 어디에 작성해야 할지 혼란이 오기 쉽다. + + - 도메인 로직에서 영속성 레이어, 엔티티 접근을 할 수 있다. + - 도메인 계층을 생략하고 영속성 계층을 웹 계층에서 접근한다. + - 도메인에 있던 레이어를 영속성 레이어 단계로 내려서 존재할 수도 있다. + + +### 동시작업이 어려워 진다. +계층형 아키텍쳐는 동시작업에 그다지 도움이 되지 않는다. 영속성 계층 위에ㅓ 만들어 지기 때문에, 영속성 계층을 먼저 개발한 뒤에 도메인을, 이후 웹계층을 만든다. +