Clean architecture is not Data - Domain - Presentation

https://markonovakovic.medium.com/clean-architecture-is-not-domain-data-presentation-e368d7ff8579

Clean Architecture is not Domain-Data-Presentation.

클린아키텍쳐를 따르면서 작업하고 있다라고 생각했던 저의 안드로이드 사이드프로젝트가 시간이 가면 갈수록 오히려 생산성을 낮추고 변경이 발생할때마다 전체 모듈을 변경을 해야하는 경우가 생기면서 의문점을 가지게 되었습니다. 

이러한 저의 고민에 대한 어느정도 통찰력이 느껴지는 미디엄 포스팅을 보았고 공유해보고자 합니다.

 

우선 저의 가장 큰 고민이었던 생산성이 낮아지고 변경사항이 한 모듈에만 그치는것이 아니라 전반적으로 모든곳에 영향을 끼치는 문제였습니다. 

저는 많은 사람들이 말하는대로 Data - Domain - Presentation 모듈을 나누고 Repository 패턴과 의존성 역전원칙을 이용해서 Data - Domain 영역간 의존성방향을 안쪽으로 향하게 하였습니다. 그러나 이러한 레이어링 과정중에 새로운 api 엔드포인트가 추가되면
1. Domain repository interface 에 api 추가

2. Data repository impl 에서 구현

3. Usecase 작성

4. Presentation 영역에서 viewmodel 와 view 추가 및 수정

이러한 단계를 거치게 되었습니다.

결국 따져보면 하나의 영향이 모든곳에서 수정이 필요한 상태가 되어버린 것입니다.

 

위 글의 저자도 제가 겪고있는일에 대해 똑같이 설명하고 있습니다.

Let’s say you have travel guide application.You create your domain module that holds model classes, usecases and repository interfaces. Then you create data module that implements those repository interfaces and then you have your presentation layer where you use and combine all of that into flow that you need and expose it to the UI. Everyone is happy. You have “Clean Architecture”. Wrong.
What happens when you want to add some functionality? Let’s say your travel destinations search functionality was just filtering destination you’ve already fetched and now you want to fetch search result’s from the server. That involves:

(domain) Adding method to the repository interface.
(data) Implementing that method in the repository implementation class.(data/network) Adding API call to your network client.
(presentation) Changing your ViewModel and UI to reflect changes.

Do you see what have we just did? We changed every layer of the app! Changes as simple as adding argument to the repository method involves changes listed above and changing every single module.
Is that easier to maintain? No, it’s pretty much the same.Did we break the monolith into smaller peaces? Meh, we just created distributed monolith.Do we have faster build times? No, we changed every module and every module need to be built again. To be fair in some situations we do have faster build times, you changed just UI for example but….
We effectively did nothing. That brings us to the biggest flaw in this layering approach.

 

이에 대해 마틴 파울러의 포스팅을 언급하면서 Domain-Data-Presentation 모듈로서의 접근은 일반적인 방법이긴 하지만 작은 단위로 나누었을때 효과를 발휘한다라고 합니다.

왼쪽처럼 전체를 나누는것이 아니라 Feature 단위 내에서 이러한 방식을 취한다면 위같은 변경 및 추가사항이 발생했을경우 다른곳에는 영향을 미치지 않는다는 것입니다.

 

작게 나누라는말은 이젠 알겠습니다. 그러면 클린아키텍쳐라는게 도대체 정확히 뭘까요 ?

 

Here is the original post by Uncle Bob on clean architecture: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html.

In this post you can see a list of what qualities Clean system has as well as explanation of the Dependency Rule. What is this Dependency Rule? From the original article:

The overriding rule that makes this architecture work is The Dependency Rule. This rule says that source code dependencies can only point inwards. Nothing in an inner circle can know anything at all about something in an outer circle. In particular, the name of something declared in an outer circle must not be mentioned by the code in the an inner circle. That includes, functions, classes. variables, or any other named software entity.

 

저자는 엉클밥의 포스팅을 인용하며 의존성 규칙의 중요성에 대해 언급하고 있습니다. 의존성 규칙이란 결국 inner circle 코드가 outer circle 에 대해 알지 못해야한다 라는 것입니다. 즉 의존성의 방향이 내부로 향해야 한다는 뜻이겠죠. 이렇게 함으로서 Entity 라고 말하는 순수한 비지니스 규칙과 로직을 지킬수 있다는 의미인 것 같습니다. 

 

 

글의 끝맺음이 깔끔하진 못한것 같지만 결국 저자가 말하고자 하는 바는 의존성 규칙, 그리고 Data-Domain-Presentation 이 클린아키텍쳐는 아니다 라는 것입니다. 그리고 작은단위로 레이어링을 유지하자 라는 것 같습니다. 

어느정도는 저도 공감을 했었고 특히 위 포스팅에 달린 댓글중에서 Android Framework 는 이러한 레이어링을 약화시키긴 하지만 결국 의존성 그 자체가 클린아키텍쳐의 메인 키인것 같다. 라는 댓글에:
Clean architecture is there to ease app development and maintenance and that's by managing dependencies. It's about correct usage of SOLID and component principles (nobody talks about those).
SOLID 원칙을 올바르게 사용하고 의존성을 관리함에 관한것이다 라는 답글을 달아줌으로써 저자의 생각을 더 정확하게 이해할 수 있었습니다.

 

여전히 고민해봐야할 문제이지만 저 또한 위 글에서 설명했던 문제들을 겪었고 고민했었기때문에 좋은 참고할만한 자료라는것은 분명해 보입니다.