2주차 WIL[Weekly I Learned] (작성중)

이번주에 배운 것 - 클린 아키텍쳐

 

1. 클린 아키텍쳐로의 여정

 

인간은 발전하는 동물이다. 아키텍쳐 방법론도 처음부터 클린 아키텍쳐가 아니었다.

 

1-1

- Layered Architecture  웹 개발시 처음 배웠던 아키텍쳐이다. 일반적으로 Presentation, Business, Persistence, DB 의 4개 Layer로 도메인을 설계하는 방법론이다. (중심 Layer는 Business Layer이다.)

 

여기서 나는 의문점이 생겼다. Persistence(영속성) 계층은 왜 존재하는걸까? DB 자체가 영속성을 가지고 있지 않나?

 

   컴퓨터공학에서 데이터는 두가지 성질을 가지고 있는 곳에 저장이 된다. volatile (휘발성)과 non-volatile (비 휘발성) 메모리이다. 기준은 컴퓨터 전원이 꺼졌을때 데이터가 보존되는지 보존되지 않는지이다. 사실 영속성만 따지면 Business Lyayer에서 바로 DB로 저장해도 문제가 없을 것이다. 하지만 이러면 몇가지 문제가 생긴다.

 

아래는 ChatGpt의 답변이다. 

 

-물음 : business layer에서 db로 바로 access 가능할 때 문제점에 대해 요약해줘

 

1. 관심사의 분리 부족

• 데이터베이스 액세스 코드와 비즈니스 로직이 혼합되어 코드 가독성과 유지보수성이 저하됩니다.
• 데이터 저장 방식 변경 시 비즈니스 로직도 수정해야 함.

---

2. 중복 코드 증가

• 데이터베이스 관련 로직이 여러 비즈니스 로직에 중복 작성될 가능성이 높아 재사용성이 낮아지고, 오류 가능성이 증가합니다.

---

3. 데이터베이스 종속성

• 특정 DBMS(SQL 문법, 라이브러리 등)에 종속되기 쉬워, 데이터베이스를 변경하거나 확장하기 어렵습니다.
• 예: MySQL에서 PostgreSQL로 전환 시 대규모 수정 필요.

---

4. 트랜잭션 관리 어려움

• Business Layer에서 여러 데이터 조작 작업을 처리할 경우, 트랜잭션의 원자성(ACID 원칙)을 일관되게 보장하기 어렵습니다.

---

5. 테스트 및 모킹 어려움

• 데이터베이스 직접 접근 코드가 많아지면, 비즈니스 로직을 독립적으로 테스트하기 어렵습니다.
• 데이터베이스를 모킹(Mock)하거나 대체하는 데 복잡성이 증가합니다.

---

6. 보안 취약점 증가

• SQL Injection 등 보안 문제가 발생할 가능성이 높습니다.
• 데이터 검증 및 접근 제어 로직이 일관되지 않을 수 있습니다.

---

7. 성능 최적화 제약

• 데이터 캐싱, 배치 처리, Lazy Loading 등 최적화 전략을 일관되게 적용하기 어려움.

---

요약

Business Layer에서 DB로 직접 접근하면 유지보수성, 확장성, 보안성이 저하되고, 테스트 및 성능 최적화가 어렵습니다. Persistence Layer를 활용하면 이러한 문제를 해결하고 구조적이고 효율적인 설계를 가능하게 합니다.

 

나는 ChatGpt 무료 플랜이라 시간이 지나면 좀 더 구체적인 질문을 해볼 것이다. 

 

 

1-2

- Hexagonal Architecture 

   Layerd Architecture의 문제점은 중심이 Business Layer지만 Business Layer의 역할이 견고하게 지켜지지 않을 수도 있다. 이런 관점에서 시작된 것이 Hexagonal Architecture이다.

//내용 추가 필요

 

1-3

- Clean Architecture

  헥사고날 아키텍쳐의 복잡성을 제거하고 Business Layer는 견고하면서도 이해하기 쉽고 깔끔(Clean)한 설계를 지향.

// 내용 추가 필요

1-4

- Clean Layered Architecture 

  레이어드 아키텍쳐에 Business Layer에 집중할 수 있도록 Repository를 interface화 시켰다. 우리는 이 방식으로 이번주 과제를 할 것이다. 

//내용 추가 필요