[Clean Architecture] 4단계의 layer로 구성된 앱의 구조

1. 위 구조의 장점

- Framework가 독립적이라 바꾸기 쉬움

- UI, DB, server없이 비즈니스 rules들을 테스트 가능 

- UI가 독립적이라 바꾸기 쉬움 (비즈니스 rules없이 바꾸기 가능)

- DB종류에 대해 독립적 (DB종류가 바뀌어도, 바뀐 부분만 수정하면 똑같은 함수를 써서 똑같은 결과를 낼 수 있는 기대)

종합적으로, 각 레이어들이 바뀌어도 다른 레이어들이 모를 정도로 독립적인 구조라서 유지보수에 좋음

독립성: 결합도(모듈과 모듈과의 상호 의존 정도)는 낮게, 응집도(내부 모듈의 기능 집중도)는 높게

 

2. 위 레이어 구성을 사용할 때의 Rules 가장 중요

- 소스코드에서도 들어나야 함: 밖 layer에서 선언된 이름/함수/클래스 이름이, 내부에서 아예 불려지지 않아야함

- 4개의 layer로 꼭 안해도, 위의 rule은 꼭 지켜져야 함

3. 각 Layer 개념

1) Entities

- Enterprise Wide라는 Business Rules를 담고 있는 레이어

- 앱에서 가장 공통적인 것 (외부가 바뀌면 가장 최소한으로 변경되는 것)

 

2) Use Case

- application specific라는 business rules를 담고 있는 레이어

- Entities로부터 data플로우들을 지휘하는 역할

- Entities들이 enterprise wide business rules을 사용할 수 있도록 관리

 

3) Interface Adapters

- Entities와 UseCase가 데이터들을 편리하게 사용할 수 있도록 Adapter로 만드는 layer (DB와 Server와의 접점 ... DAO와 같은 것)

- i.e) DB종류 중 어떤것을 사용하던 간에, 이 layer는 모르고 있어야함 (getUserData, saveUserData와 같은 함수가 존재하는 레이어)

 

4) Frameworks and Drivers

- framework나 tool로 구성 (DB, Web framework)

- DB나 Web에 대하여 구체적으로 정의되어 있는 곳

 

* 출처: Robert C. Martin,  'clean code'