Clean Architecture

개발자로써의 고민

개발자로써 가장 고민이 되는 것 중 하나가 바로 유지 보수 입니다.하나의 기능에 대해 일련의 과정을 거친 후 끝이 아닌 버그, 기능 개선 등의 유지 보수 활동이 이어질 것이 예상되기 때문이다. 해당 활동에 있어서 가장 중요한 것은 유연하게 대처할 수 있어야 한다는 것일 것입니다.
이를 위해 선행되어야 되는 것이 개발 전 어떻게 개발을 할 것인지에 대한 고민 즉, 아키텍처에 대한 고민일 것입니다.

위의 고민으로 출발하게 되어 아키텍처를 공부하기위해 살펴보는 중에 Clean Architecture라는 것을 알게 되었습니다.

 

 

Clean Architecure란?

현재까지 대부분의 아키텍쳐들은 세부 사항이 다르지만 유사한 형태를 보입니다. 그것은

각각의 모듈은 분리

 

일 것입니다. 소프트웨어를 계층으로 분리하여 생각합니다. 구체적으로 시스템은

• 프레임워크에 독립적임 > 시스템을 프레임워크에 제약조건에 자유롭게 함 
• 테스트가 가능
• UI와 독립적임 > 비즈니스 로직과는 별개로 UI를 변경할 수 있음
• 데이터베이스와 독립적임 > 비즈니스 로직은 데이터베이스에 바인딩 되지 않고, 경우에 따라 유연하게 교체도 가능
• 외부 환경에 독립적 > 비즈니스 로직은 외부 환경을 알 필요가 없음

위와같은 대부분의 아키텍쳐들의 특징을 Clean Architecure는 하나의 실행가능한 모듈로 통합해보자는 개념으로 출발합니다.

 

Clean Architecure의 구조

종속성 규칙

• 소스코드의 종속성은 안쪽으로만 가리킴
• 내부 원은 외부 원에 대해서 알 수 없음
  (외부 원에서 선언된 함수, 변수 등은 내부 원에서 언급되어서는 안됨)

일반적인 Clean Architecure의 구조

Entities

• 메소드가 있는 객체, 데이터 구조 및 함수 집합
• 외부의 변경이 있을 시에, 가장 영향이 적을것으로 예상됨
  • 개체가 페이지 탐색, 보안 변경에 의해 영향을 받지 않을 것으로 예상됨
  • 운영상의 변경은 Entity 계층에 영향을 주지 않아야함

Use Case

• 애플리케이션 별 비즈니스 규칙
• Entity 간 데이터 흐름을 컨트롤 하고, 해당 Entity가 비즈니스 규칙을 사용하도록 지시함
• 이 계층의 변경이 Entity에 영향을 미치지 않음
• 이 계층이 데이터베이스, UI 등의 외부 요소의 변경에 영향을 받지 않음
• 하지만 해당 프로그램 작동에 대한 변경사항이 이 계층에 영향을 미칠것으로 예상됨

Interface Adapters (Controllers, Gateways, Presenters)

• Entity와 Use Case의 데이터를 외부 (데이터베이스, 웹 등)에 편리한 포맷으로 데이터를 전달하는 어댑터 집합

Frameworks and Drivers(Devices, Web, UI, External Interfaces, DB)

• 데이터베이스 웹 프레임워크 등
• 해당 부분은 가장 외부에 위치함
  
  
  

종속성 규칙

• 소스 코드의 종속성은 항상 안쪽을 가리킴 (바깥쪽으로 가리키지 않음)
• 바깥에서 안쪽으로 진입할 수록 낮은 수준에서 높은 수준으로 캡슐화가 됩니다.
  • 원의 안쪽으로 가면 갈 수록 고수준으로 좀 더 추상화된 개념

혼자 영문 블로그 한페이지를 보고 개념만 익히기 위해서 정리해보았습니다.
혹시 틀린게 있다면 말씀 부탁드립니다.

다음엔 Android에서의 Clean Architecure 관련 내용 정리 예정입니다.

참고 블로그
: http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html