개요
인프런을 통한 멘토링중 멘토님께서 보내주신 robert c. martin님의 클린 아키텍처 강연을 보고 적은 글입니다.
느낀점
발표를 보고 난후에는 클린 아키텍처는 코드뿐만이 아닌 애플리케이션자체의 유지보수성을 위해서 필요하구나 라고 느끼게되었습다.
물론 robert c. martin님께서는 에플리케이션은 중요한게아니라고 말씀하십니다.
(제가 생각한게 틀린것 일수도있습니다.)
목적
많은 종류의 아키텍처가 있겠지만 세부적인 차이는 존재해도 공통의 목표는 관심사의 분리이다.
구조
[출처]https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
Entities:
전사적 비즈니스 규칙을 캡슐화한 계층이다. 엔티티는 제일 높은 고수준의 계층으로 외부적인 변화(db의변경, 보안 변경등..)에 대해 아키텍처적으로 보장되어야한다.
Use cases:
애플리케이션 계층이라고도 불리며 애플리케이션별 비즈니스 규칙이 포함되어 있다.
시스템의 모든 usecase를 캡슐화하고 구현한다. 이러한 usecase는 엔티티간 데이터 흐름을 조정하고 해당 엔티티가 전사적 비즈니스 규칙을 사용해 목표를 달성토록 지시한다.
이 계층또한 고수준의 계층으로 외부변화에 영향을 받지 않는다.
Interface Adapters:
이 계층은 DB나 Web, UI와 같은 바깥의 계층에서 사용하기 편리하도록, 유즈케이스 또는 엔티티계층에서 데이터를 변환하는 어뎁터의 집합으로 GUI, MVC패턴을 포함한다.
Frameworks & Drivers:
인프라 계층이라고도 불리며, 가장 저수준의 계층으로 DB, 웹 프레임워크와 같은 세부 정보를 나타내는 계층이다. 이 계층은 시간이 지남에 따라 구성이 변경될 수 있어 내부 계층에 영향을 주지않는 외부에 보관합니다.
특징:
1.좋은 아키텍처는 프레임워크를 비판적으로 보기에 프레임워크에 종속되지 않는다.
2.비즈니스 규칙을 테스트를 함에 있어 UI, 데이터베이스, 웹 서버 또는 기타 외부 요소 없
이 테스트가 가능하다.
3.시스템의 변경 없이 UI를 쉽게 변경할 수 있어 UI와 독립적이다.
4.데이터베이스와 독립적이다.
5.외부 기관으로부터 독립적이다.
주요 원칙
위 구조의 원은 소프트웨어의 다양한 영역을 나타낸다. 안쪽으로 들어갈수록 높은 수준의 계층을 나타낸다.
이런 아키텍처가 동작하기 위한 최우선 규칙은 종속성 규칙이다.
이 규칙에 따르면 모든 소스코드의 의존성은 반드시 외부에서 내부로 향해야 한다고 한다.
즉 비즈니스 로직은 DB, Web과 같은 세부 사항에 의존해서 세부 사항의 변경에 영향을 받으면 안된다고 한다.(외부 원에서 선언된 함수, 클래스, 변수 또는 기타 명명된 소프트웨어 엔티티가 내부 원의 코드에서 언급되어서는 안된다.)
-아키텍처는 의도를 표현한것
-DB는 저장소이자 디테일로 아키텍처에 영향을 주어서는 안된다.
-좋은 아키텍처는 중요한 의사 결정을 뒤로 미룰수 있게 해준다.
참고 https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
