Clean Architecture 번역

DesignPattern

Clean Architecture 번역

nelhwu90 openDatabase 2017.12.26 14:29

The Clean Architecture

 - Uncle Bob

 

Hexagonal Architecture, Onion Architecture , Screaming Architecture, DCI, BCE 같은 아키텍쳐는  다음과 같은 system을 생산한다.

 공통점은 소프트웨어를 층으로 나누어 분리 시키는 것. 각각은 비즈니스 규칙을 위한 계층이 하나 이상있고, 인터페이스를 위한 계층도 다르다. 

1.  프레임워크의 독립성. 

라이브러리나 기능의 의존하지 않고 제한된 제약조건에 따르지않고,  프레임워크의 툴로서 사용된다. 

2. 테스트 가능한

 비즈니스 규칙은 UI,DB,Web Server ,다른 외부 요인 없이 테스트가 가능하게 할수있다.

3. UI의 독립성

UI에 관계없이 비즈니스 로직을 변경하지 않고 쉽게 변경가능하다. 

4. DB의 독립성 

Oracle,SQL , Mongo, CouchDB, 혹은 다른것들이 DB에 바인딩 되어 있지않다. 

5. 외부기관의 독립성

위에 도표는 모든 아키텍쳐를 실행가능하게 통합하려는 시도이다. 

The Dependency Rule

동신원의 레이어는 서르다른 영역을 나타낸다. 일반적으로 깊어질수록 높은수준의 소프트웨어가 된다. 

바깥쪽원은 mechanisms을 나타내고, 안쪽으로 갈수록 정책적이면을 뜻한다. 

이 아키텍쳐를 동작하게 만드는 가장 우선 규칙은 종속성 규칙이다. 

이 규칙은 종속성이 안쪽 방향으로만 가리킬수있습니다. 

1. 안쪽 원은 바깥쪽에서 무슨일을 하는지 알 수 없다. 

- 바깥쪽에서 선언된 이름이 안쪽에서 언금 되어져서는 안된다.(함수, 클래스, 변수, 어떠한 Entity포함)

2. 외부에서 사용되는 동일한 토큰, 데이터형식을 내부에서 사용해선 안된다. 

      - 외부 원안에서 프레임 워크가 데이터 형식을 생성하는 경우 더욱 그렇다. 

우리는 바깥원은 내집단에 영향을 미치지 않기를 바란다. 

Entity

Entity는 전체 비즈니스 규칙이다. 

Entity는 Object, Method, 기능의 집합 구조, 등 여러가지가 될 수 있다. 

기업 내의 애플리케이션에서 엔티티를 사용할수있으면 문제가 되지 않는다. 

만약 외부적인 변화가 있을때 변화의 영향을 덜 받는다. 예를 들어 이러한 개체는 페이지 탐색 또는 보안 변경의 영향을 받지 않을 것이다. 특정 어플리케이션 운영상의 변화가 엔티티 계층에 영향을 미쳐선 안된다.  

UseCase

이 계층의 소프트웨어는 애플리케이션 관련 비즈니스 규칙이 포함한다. 

시스템의 UseCase를 캡슐화하고, 구현합니다. 

이러한 사용 사례는 객체 간의 데이터 흐름을 조정하고, 이러한 엔티티가 기업 전체 비즈니스 규칙을 사용하여 활용 사례의 목표를 달성하도록 유도합니다. 

이 계층의 변화가 entities에 영향을 미치지 않길 기대 한다. 또한 반대로 어떤 공통의 프레임 워크의 외부 변화에 영향을 받을것도 기대하지않는다. DB, UI

하지만 영향을 받기 마련이다. 일부코드는 영향을 확실히 받는다. 

Interface and Adapters

이 계층은 데이터를 UseCase 및 Entity의 형식에서 웹 과같은 일부 외부로 변환하는 어댑터 집합이다. 

단순히 GUI의 MVC아키텍쳐에서 프레젠터, 뷰, 컨트롤러가 모두 이곳이 엤다. 모델은 컨트롤러 에서 UseCase로 전달된 후 다시 UseCase에서 Presenter, Views로 전달되는 데이터 구조일 뿐이다. 

또한 외부 서비스와 같은 특정 외부 형식에서 사용사례 및 엔티티에서 사용하는 내부 형식으로 데이터를 변화하는 데 필요한 기타 어댑터도 있습니다. 

Frameworks and Drivers. 

바깥쪽의 층은 일반적으로 데이터이스 , 웹 프레임 워크와 같은 도구들로 구성되어 있다. 일반적으로 당신은 다음 원 안으로 전달하는 글루 코드외에는 많은 코드를 쓰지 않는다. 

Only Four Circles ?

여러분은 아마도 이 네개 이상이 필요하다는 것을 알게 될 것이다. 항상 이 4개만 가지고 있어야 한다는 규칙은 없어요. 그러나 종속성 규칙은 항상 적용됩니다. 소스 코드 종속성은 항상 안쪽을 가리킵니다. 추상화 증가 수준으로 이동함에  따라 가장 바깥 원은 낮은 수준의 콘크리트 상세 정보입니다. 안쪽으로 이동하면 소프트웨어가 더 추상화되고 상위 수준 정책을 캡슐화합니다. 내면의 가장 일반적인 원은 가장 평범한 원입니다.

Crossing boundaries. 

다이어그램의 오른쪽 아래에는 원의 경계끼리의 교차 방법이다.

컨트롤러 및 Presenter 통신이 다음 계층의 사용사례와 통신하고 있음을 보여 줍니다. 

제어 흐름을 알아야한다. 컨트롤러에서 시작하여 UseCase를 거친 후 Presenter를 실행하는것으로 끝난다. 

소스 코드 종속성에 주의해라.

Dependency Rule에 의해 의존적인 규칙을 명백한 모순을 의존관계 역전 원칙에 의해 해결하고 제어흐름을 반대록 인터페이스와 상속관계를 조정한다. 

UseCase 에서 Presenter를 호출해야 하지만, 이 call이 직접적으로 호출되어서는 안된다. 

바깥 원에 있는 Name이 내부원으로 언급되어질 수 없다. 따라서 우리는 인터페이스라는 활용사례를 내부 그룹에 두고 외부그룹의 Presenter에서 구현하도록 하고 있다.