Software architecture란?
문자 그대로 소프트웨어 구조라는 뜻이다. 소프트웨어가 어떻게 구성되어있는지, 구성 요소간의 관계는 어떤지, 어떻게 동작하는지 등을 의미하며, 소프트웨어의 구조를 설계하는 방법까지도 뜻을 내포한다.
어떤 구조가 좋은 구조인지는 소프트웨어의 성격과 목적에 따라 다르겠지만, 공통적으로 유연하고 관리하기 쉬운 구조를 지향한다고 생각한다.
Software architecture에는 다양한 패턴이 있지만 그 중 일반적으로 많이 사용하는 Layered architecture에 대해 알아보고 이후 Clean Architecture에 대해 추가적으로 알아보자.
Layerd architecture
계층화 구조는 명칭 그대로 소프트웨어를 계층으로 나눠서 구조를 설계하는 방식이다. Layerd architecture 역시 유연하며, 관리하기 쉬운 소프트웨어를 개발하기 위해 나온 구조이다.
Layerd architecture는 레이어 별로 작업을 나눠서 처리하며 최소 4단계의 계층을 갖는다.
출처 : https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch01.html
Presentation Layer에는 사용자 인터페이스나 브라우저 통신 등을 처리한다. Business Layer에서는 실제적인 서비스를 구현하는 비즈니스 로직이 있고, Persistence Layer는 데이터베이스에 객체를 매핑시키는 역할을 하고, Database Layer에서는 이를 처리한다.
이 구조의 핵심은 수행하는 동작을 분리시키고, 하위 레이어에만 의존하도록 하는 것이다. 예를 들면 Presentation Layer는 하위 레이어인 Business Layer에만 의존하여 동작한다. 그 아래 계층인 Persistence Layer에서 무슨 처리를 하는지 알 수 없으며, 변화가 생기더라도 문제가 없다.
이 구조의 장점은 우선 각 계층이 확실하게 분리되어 있기 때문에 테스트 하기가 쉽다는 점이다. 각 계층을 유연하게 변경할 수 있다. 예를 들면 가장 상위 계층인 Presentation Layer를 변경하면 시스템 전체를 수정하지 않고도 웹에서 동작하던 것을 앱에서 동작하게 할 수도 있다.
하지만 한 기능을 수행하기 위해서 여러 계층을 거쳐서 동작하기 때문에 성능이 낮고, 가장 하위 계층인 데이터 베이스에 의존적이라는 단점이 있다.
Screaming architecture
Clean architecture를 보기 전에 Screaming architecture에 대해서 먼저 알아보자. Screaming architecture는 Robert C. Martin이 제안한 구조이다. 소프트웨어의 구조가 소리치듯이 구조만 봐도 어떤 서비스 인지 알 수 있어야 한다는 의미를 가지고 있다.
앞에서도 말했듯 Screaming architecture의 핵심은 구조만 보고도 소프트웨어가 무엇인지 알 수 있도록 명확해야 한다는 것이다. 때문에 이 구조는 소프트웨어가 무슨 기능을 하는지에 초점을 맞춰 구조를 설계한다.
이 구조는 내가 만들었던 프로젝트 중 하나이다. 글을 작성하거나 보는 게시판 기능을 제공하는 서비스인데 구조만 보면 어떤 서비스인지 전혀 예측 할 수 가 없다.
Screaming architecture에서는 서비스가 어떤 비즈니스 로직을 제공하는지가 중점이 되어 소프트웨어의 구조를 결정한다.
이런식으로 설계하면 구조만 봐도 어떤 서비스인지 명확히 알 수 있다. 이 방식을 적용한다면 시스템이 더 확장되더라도 기능을 명확하게 파악할 수 있을 것 같아 보인다.
Clean architecture
Clean Architecture 역시 Robert C. Martin이 제안한 아키텍처 패턴이다. Clean Architecture는 다른 방법과 같이 유연하고 관리하기 쉬운 소프트웨어 구조를 지향한다.
Clean architecture는 Screaming architecture에서 좀 더 발전한 구조라고 생각한다. Clean architecture는 비즈니스 규칙/로직를 중심으로 구조를 설계한다.
출처 : https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
양파 모양처럼 생겼지만 각각이 계층으로 이루어진 구조라고 보면 된다. 안쪽으로 갈수록 추상화 된 개념이다. 데이터가 각 계층을 이동할 때에는 가장 단순한 데이터 구조로 이동하며, 각 계층은 하위 계층에게만 의존한다.
Entities는 객체를 표현하며, Use Cases에서는 Entity들을 이용하여 비즈니스 로직을 구현한다. 초록색 계층인 Interface Adapters는 비즈니스 로직을 외부 형식으로 변환하며, 파란색 계층인 Frameworks and Drivers는 프레임워크 영역이다. DB 설정, 웹 통신 설정 등을 구현한다.
이 구조는 프레임워크에 독립적이다. 웹 같은 UI 뿐만 아니라 데이터 저장에도 독립적이며, 그 외 어떠한 외부 사항이 변하더라도 고유한 비즈니스 로직을 유지 할 수 있다. 만약 DB를 바꾸거나 통신 방식을 변경하더라도 세부 설정만 변경하면 그대로 사용할 수 있게 되는 것이다.
느낀점
사실 그동안 개발하면서 프레임워크에 의존한 구조만을 선택해왔다는 것을 깨달았다. 어떤 선택지들이 있는지도 모른채 개발 해왔다. Software architecture를 공부하면서 다양한 방법론이 있다는 것을 새삼스럽게 깨닫게 되었고, 앞으로는 목적에 따라서 구조를 선택해야겠다는 것을 느꼈다.
출처
https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch01.html
https://blog.cleancoder.com/uncle-bob/2011/09/30/Screaming-Architecture.html
https://levelup.gitconnected.com/what-is-screaming-architecture-f7c327af9bb2
https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
https://logistikknowhow.com/en/it-and-software/definition-of-the-software-principle-clean-architecture/
