[Architecture] The Clean Architecture - 1

https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

Clean Coder Blog

---

이번 글은 Swift 도 iOS 도 아닌 다른 종류의 글을 써본다  번역해본다. 총 2편으로 나눈다.

바로바로 Robert C. Martin (Uncle Bob)의 Clean Architecture 글이다.

2012년도에 쓰여진 글이지만 아주 좋은 글이라고 생각이 된다.

그렇다면 시작해보자!

몇 년간 우리는 시스템 아키텍처에 관련된 다양한 아이디어들을 봤다.

• Hexagonal Architecture (https://alistair.cockburn.us/hexagonal-architecture/)
• Onion Architecture (https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/)
• Screaming Architecture (https://blog.cleancoder.com/uncle-bob/2011/09/30/Screaming-Architecture.html)
• DCI (http://www.amazon.com/Lean-Architecture-Agile-Software-Development/dp/0470684208/)
• BCE (http://www.amazon.com/Object-Oriented-Software-Engineering-Approach/dp/0201544350)

이러한 아키텍쳐들은 세부적으로 보면 서로 다른 부분이 많지만, 매우 비슷하다.

그들은 모두 중요한 것(concerns)들의 분리라는 공통된 목표를 갖고 있다. 그들은 모두 소프트웨어를 여러 단계의 레이어로 나누면서 이러한 목표를 이룬다. 각각의 아키텍처들은 적어도 하나의 비즈니스 룰과 하나의 인터페이스를 갖고 있다.

 

각각의 아키텍쳐들은 다음과 같은 시스템을 제공한다

1. 프레임워크로부터의 독립. 아키텍처는 기능이 포함된 소프트웨어의 라이브러리에 의존하지 않는다. 이는 프레임워크의 제한에 네 시스템을 구겨 넣는 게 아니라, 너로 하여금 프레임워크를 도구로서 사용하게 한다.
2. 테스트 가능함. 비즈니스 룰들은 UI, 데이터베이스, 웹 서버, 또는 다른 외부적인 요인 없이도 테스트가 가능하다.
3. UI 로부터의 독립. 시스템의 변화 없이 UI는 쉽게 변할 수 있다. 예를 들어, 비즈니스 룰 없이도 웹 UI는 콘솔 UI로 바뀔 수 있다.
4. 데이터베이스로부터의 독립. 너는 Oracle, SQL Server 를 Mongo, BigTable, CouchDB 또는 다른 DB로 변경할 수 있다. 네 비즈니스 룰들은 특정 데이터베이스에 갇혀 있지 않는다.
5. 외부 요인으로부터의 독립. 네 비즈니스 룰들은 외부 세계에 대해 아무 것도 알지 못한다.

위에 있는 다이어그램은 이러한 모든 아키텍쳐를 하나의 실행 가능한 아이디어로 통합하려는 시도이다.

The Dependency Rule

여러 동심원들은 소프트웨어의 서로 다른 영역을 나타낸다. 일반적으로, 더 깊게 들어갈수록, 더 높은 레벨의 소프트웨어가 나타난다. 바깥쪽 원들은 메커니즘이다. 안쪽 원들은 정책들이다.

이 아키텍쳐가 성립되게끔 하는 가장 중요한 규칙은 The Dependency Rule이다.

이 규칙은 소스코드의 의존성은 오직 안쪽으로만 향할 수 있다는 것이다.

안쪽에 있는 원은 바깥쪽에 있는 원에 어떤 것이 있는지 전혀 알 수 없다. 일반적으로, 바깥쪽 원에서 선언된 것들의 이름은 절대로 안쪽 원에서 언급되서는 안 된다. 함수들, 객체들, 변수들, 또는 소프트웨어 엔티티들을 포함한다.

같은 이유로, 바깥쪽 원에서 사용된 데이터 포맷들은 안쪽 원에서 사용되서는 안된다. 특히, 그 포맷들이 바깥쪽 원에서 프레임워크가 생성한 것이라면 더욱 안된다. 우리는 바깥쪽 원에 있는 것들이 안쪽 원에 영향을 주는 것을 원치 않는다.

Entities

엔티티들은 Enterprise wide 비즈니스 룰들을 캡슐화한다. 엔티티는 메서드를 가진 객체가 될 수도 있고, 데이터나 구조와 함수들의 세트가 될 수도 있다. 엔티티가 기업의 다양한 응용 프로그램에서 사용될 수 있는 한 문제가 되지 않는다.

만약 기업이 없고, 단지 단일 응용 프로그램을 작성하는 경우, 이러한 엔티티들은 응용 프로그램의 비즈니스 객체가 된다. 이 엔티티들은 가장 일반적이고 높은 레벨의 규칙들을 캡슐화한다. 이들은 다른 외부의 변화에도 가장 적게 변한다. 예를 들어, 페이지 내비게이션, 보안의 변화에도 이러한 객체들이 영향을 받는 것을 원치 않을 것이다. 특정 애플리케이션의 운영상의 변화는 엔티티 계층에 변화를 주어서는 안 된다.

Use Cases

이 레이어에 있는 소프트웨어는 application specific 비즈니스 룰을 갖는다. 이는 시스템의 모든 사용 사례들을 캡슐화하고 구현한다. 이러한 사용 사례들은 엔티티로 들어가고 나오는 데이터를 조율하고 엔티티들이 갖고 있는 enterprise wide 비즈니스 룰들을 사용해서 사용 사례들의 목적을 달성하게끔 감독한다.

이 레이어의 변화가 엔티티들에 영향을 끼치는 것을 원치 않는다. 또한, 데이터베이스, UI, 또는 다른 공통 프레임워크로부터 이 레이어가 영향을 받는 것을 원치 않는다. 이 레이어는 다른 중점(concerns)으로부터 독립되어 있다.

그러나, 응용프로그램 운영 변화가 사용 사례와 이 레이어의 소프트웨어에 영향을 주는 것은 기대한다. 만약 사용 사례들의 세부 사항에 변화가 생긴다면, 이 레이어의 몇몇 코드들은 분명히 영향을 받을 것이다.

Interface Adapters

이 레이어의 소프트웨어는 사용 사례와 엔티티에서 가장 편리한 포맷의 데이터를 데이터베이스 또는 웹과 같은 외부 요인에 가장 편리한 포맷의 데이터로 변환해주는 여러 개의 어댑터들을 갖고 있다. 예를 들어, 이 레이어에는 GUI의 MVC 아키텍처를 갖고 있을 수 있다. Presenters, Views, Controllers 가 여기에 속한다. 모델들은 controllers에서 use cases로, use cases에서 presenters, views로 되돌아오는 데이터 구조를 갖는다.

마찬가지로 이 계층에서 데이터는 엔티티 및 사용 사례에 가장 편리한 형태에서, 사용 중인 지속성 프레임워크(데이터베이스)에 가장 편리한 형태로 변환된다. 안쪽 원의 어떤 코드도 데이터베이스에 대해 알 수 없다. 만약 데이터베이스가 SQL database 라면, 모든 SQL 은 이 레이어에 제한되고, 특히 데이터베이스와 관련된 부분은 이 레이어의 부분으로 제한되어야 한다.

또한, 이 레이어에는 외부 서비스와 같은 외부에 있는 데이터 형태를 사용 사례와 엔티티에 사용되는 내부에 있는 데이터 형태로 변환해주는 어댑터도 존재한다.

Frameworks and Drivers

최외각의 레이어는 데이터베이스, 웹 프레임워크와 같은 프레임워크와 툴들로 이루어져 있다. 일반적으로 다음 내부 원과 통신하는 glue code 가 아니라면 이 레이어에서는 그다지 많은 코드를 작성하지 않는다.

이 레이어는 모든 세부사항들이 담긴다. 웹, 데이터베이스는 세부사항이다. 이러한 것들을 바깥쪽에 둠으로써 시스템 전체에 적은 해를 끼치게 한다.

 

여기까지 Clean Architecture 1편을 마친다.