Notice
Recent Posts
Recent Comments
Link
«   2024/12   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31
Archives
Today
Total
관리 메뉴

개발자의 삽질

[Architecture] The Clean Architecture - 2 본문

Architecture

[Architecture] The Clean Architecture - 2

uniqueimaginate 2022. 1. 7. 23:20

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

 

Clean Coder Blog

The Clean Architecture 13 August 2012 Over the last several years we’ve seen a whole range of ideas regarding the architecture of systems. These include: Though these architectures all vary somewhat in their details, they are very similar. They all have

blog.cleancoder.com


1편에 이어 2편을 쓴다.

1편: 2022.01.05 - [Architecture] - [Architecture] The Clean Architecture - 1

Only Four Circles?

아니다. 위의 원은 개략적인 그림일 뿐이다. 필요하다면 4개의 원보다 더 많은 원을 찾을 수도 있다. 절대로 4개의 원만 존재해야 하는 법은 없다. 그러나, The Dependency Rule는 언제나 적용된다. 소스 코드의 의존성은 언제나 안쪽 원으로 향한다. 더 안쪽으로 이동할 수록 추상화의 단계는 더 높아진다. 가장 바깥쪽 원은 낮은 단계이며 구체적인 세부사항이 있다. 안쪽 원으로 이동하면 할수록 소프트웨어는 더 추상적일 것이고 더 높은 단계의 정책들을 캡슐화하게 된다. 가장 안쪽 원은 가장 개괄적이다.

Crossing boundaries

다이어그램의 오른쪽 아래에는 원을 건너는 방법에 대한 예시가 있다. 이는 다음 레이어의 사용사례를 이용하여 통신하는 Controller와 Presenter를 보여줍니다. 이 흐름을 보자. Controller에서 시작해서 사용 사례를 거쳐 Presenter에서 실행되면서 마무리된다. 소스 코드의 의존성도 보자. 각각은 사용 사례를 향해 있다.

우리는 보통 Dependency Inversion Principle 을 이용하여 이러한 모순을 해결한다. 예를 들어, Java와 같은 언어에서는 인터페이스와 상속를 정렬하여 경계를 가로지르는 올바른 지점에서 종속성이 제어 흐름에 반대되도록 합니다.

예를 들어, 사용 사례가 presenter를 호출한다고 해보자. 그러나, 이러한 호출은 The Dependency Rule: 바깥 쪽 원에 있는 이름이 안쪽 원에서 호출되지 않는다  원칙을 위배하기 때문에 직접 호출을 해서는 안된다. 따라서 사용 사례가 인터페이스를 안쪽 원에 갖고 있고 바깥쪽 원에 인터페이스를 구현하는 presenter를 갖고 있다.

경계면을 넘나들기 위해 아키텍처들에는 이러한 같은 기법들이 사용된다. 우리는 제어 흐름의 방향이 어디로 가는지와 상관없이 The Dependency Rule 을 지키기 위해, 제어 흐름에 반대하는 소스 코드의 의존성을 생성하는 동적 다형성의 장점을 사용한다.

What data crosses the boundaries

일반적으로, 경계를 넘는 데이터들은 단순한 자료 구조들이다. 단순한 구조체 또는 단순한 Data Transfer Object(DTO)를 사용할 수 있다. 또는 단순히 함수 호출 인자가 될수도 있다. 또는 해쉬맵이나 객체로 만들수도 있다. 중요한 점은 단순하고 독립된 자료 구조들이 경계를 넘는다는 것이다. 엔티티나 데이터베이스 행을 속여서 넘기고 싶지 않다. 데이터 구조가 The Dependency Rule을 위배하는 어떤 종류의 의존성도 갖기를 원치 않다.

예를 들어, 많은 데이터베이스 프레임워크들은 요청에 대해 편리한 데이터 형태로 반환한다. 우리는 이를 RowStructure라고 부른다. 우리는 이러한 행 구조를 안쪽 경계로 보내고 싶지 않다. 이는 안쪽 원이 바깥쪽 원의 무언가를 알게끔 하기 때문에 The Dependency Rule 을 위배한다.

따라서 경계면을 넘어 데이터를 보내고 싶다면, 그 데이터의 형태는 언제나 안쪽 원이 가장 편하게 사용되는 형태여야 한다.

Conclusion

이러한 단순한 규칙들을 지키는 것은 그리 어렵지 않고 앞으로 있을 많은 고민으로부터 자유롭게 해줄 것이다. 소프트웨어를 여러 레이어로 나누고 The Dependency Rule을 지킨다면 본질적으로 테스트가 가능하고 이로인해 얻는 장점을 가지는 시스템을 만들 수 있을 것이다. 만약 데이터베이스나 웹 프레임워크와 같이 시스템의 외적 부분이 오래되었다면, 이러한 부분들을 적은 노력으로 쉽게 변경할 수 있다.

 

이상으로 Clean Architecture 2편을 마친다.
핵심은 Layer를 만들고 The Dependency Rule을 지키자!

'Architecture' 카테고리의 다른 글

[Architecture] The Clean Architecture - 1  (0) 2022.01.05
Comments