https://www.thinktocode.com/2018/07/05/layered-architecture/ 를 번역합니다.
의역이 다소 섞여있을 수 있습니다.
서론
Layer에 대해 들어본 적이 있나요? 소프트웨어 아키텍처 중 가장 잘 알려진 것이 레이어드 아키텍처입니다. 어플리케이션을 레이어링하는 것은 커다란 진흙 덩어리를 제거하거나 애초에 그런 일이 발생하는 것을 예방하는 도구 중 하나라고 할 수 있습니다.
여기서 일컫는 커다란 진흙 덩어리란 계층화나 관심사에 대한 분리가 이뤄지지 않은 어플리케이션이며 이러한 어플리케이션은 모든 것들이 얽혀 문제들과 연결될 수 밖에 없습니다. 쓸데없이 커다래진 컨트롤러를 가지고 있거나, persistence 메커니즘을 위한 단일 공간이 없을 수도 있습니다.
뛰어난 소프트웨어 개발자라면 코드를 개발하고 읽는 것이 쉬우며 기능에 따라 잘 분리된 코드를 가지는 아키텍처를 원할 것입니다. layer를 고려한다면 이러한 목표에 도달하는 것이 더 쉬워질 것입니다.
레이어드 아키텍처란?
레이어드 아키텍처는 각 레이어에 특정 관심사와 관련된 개체만을 포함하게 만듬으로써 관심사가 분리된 코드 구성을 목표로 합니다.
계층화된 시스템에서 각 계층은 그 아래에 있는 계층에 종속됩니다. 반대로 아래 계층은 상위 계층에 대한 어떠한 지식(이해)도 없어야 합니다.
엄격한 계층화에서는 정확히 그 아래에 있는 하나의 계층에만 엑세스할 수 있어야하며, 보다 유연한 접근 방식을 사용하면 현재 레이어 하위의 모든 레이어를 엑세스하는 것이 가능합니다. 경험상 전자의 경우 값을 제공하지 않는 많은 오버 헤드 코드를 생성할 수 있기 때문에 후자를 추천합니다.
유연한 계층 구조에서는 프레젠테이션 계층에서 인프라 계층의 레포지토리를 엑세스 할 수 있음을 의미합니다.
왜 레이어드 아키텍처를 사용할까?
레이어드 아키텍처는 관심사에 대해 생각할 기회를 줍니다. 그리고 깨끗하고 더 잘 분리된(more decoupled) 코드에 대해 고민할 수 있게 만듭니다. 특정 레이어에서 작업할 때 상위 레이어에 대해서는 고민할 필요없이 단지 현재 레이어와 그 아래에 있는 레이어만 생각하면 됩니다. 이는 우리가 현재 작업중인 것에만 집중할 수 있게 해줍니다.
여러 상위 레벨 레이어가 있는 경우에도 하위의 한 레이어를 쉽게 사용할 수 있습니다. 예를 들어 API 프레젠테이션과 웹 프레젠테이션(상위)이 동일한 어플리케이션 레이어(하위)를 사용하나 서로 완전히 분리되게 만들 수 있습니다. 이는 프레젠테이션 레이어에서 도메인 레이어와 어플리케이션 레이어를 분리시켰기에 가능합니다.
4-Layer Architecture
앞에서 4개의 레이어가 있는 이미지를 보았습니다. 이제 각각이 하는 일에 대해 빠르게 살펴보도록 하겠습니다.
도메인
Domain 혹은 Business Logic Layer는 시스템의 코어입니다. 모든 비즈니스 모델과 서비스는 여기에 정의되어 있습니다. 이 계층은 비즈니스 규칙과 로직을 포함하고 있습니다. 시스템에서 가장 중요한 계층이라고 할 수 있습니다.
어플리케이션
Application Layer는 모든 것을 하나로 묶습니다. 즉, 어플리케이션의 오브젝트와 서비스를 조정합니다. 비즈니스 로직과 프레젠테이션 간의 인터페이스라고 할 수 있습니다.
Application service는 어플리케이션이 구동하는 방식을 보여줍니다.
프레젠테이션
Presentation 혹은 UI Layer 뷰, 템플릿, 컨트롤러, 폼을 의미합니다. 이는 외부 세계(사용자나 다른 시스템)를 위한 인터페이스입니다. 개발한 시스템의 소비자가 볼 수 있는 모든 것들은 프레젠테이션 영역입니다. 이는 웹 페이지나 Restful API일 수 있습니다. 시스템과 외부와의 상호 작용은 이 계층을 통해 이루어져야합니다.
인프라스트럭쳐
Infrastucture Layer는 가장 낮은 수준(가장 높은 추상화 정도)의 코드를 포함합니다. 예를 들자면 데이터베이스나 이메일 혹은 메시징 큐(실제 큐나 이메일을 전송하는 것)와 같은 외부 서비스와의 상호작용을 맡습니다. 이 레이어에 위치한 모든 것들은 쉽게 교체될 수 있어야합니다. 또한 여기에 포함된 코드들은 (비즈니스) 로직에 관련된 어떤 것이나 어플리케이션의 작동 방식에 영향을 주지 않아야합니다. 이 곳의 코드는 본질적으로 details입니다.
라자냐 아키텍처
더 많은 레이어가 있다면 라자냐 아키텍처가 될 수 있습니다. 하지만 이는 큰 라자냐 더미가 될 뿐입니다. 소스가 층 사이로 흐르고 엉망이 될 수 있습니다. 즉, 코어를 더욱 복잡하게 만듭니다.
4개 이상의 레이어를 가질 이유가 없습니다. persistence를 위해 추가 계층을 생성하고 어플리케이션과 도메인을 여러 계층으로 분할 할 수 있으나 그럴 이유가 없다면 단순하게 유지하는 것이 좋을 것입니다.
결론
레이어드 아키텍처는 관심사의 분리에 관한 것임을 기억하는 것이 중요합니다.
코드 캡슐화와 분리는 어플리케이션 내에서 기능적 역할에 따라 코드를 그룹화함으로써 수행 할 수 있습니다.
하지만 중요한 것은 많은 레이어를 만드는 것은 좋지 않다는 점입니다. 여기서 언급된 4개의 레이어만 사용하는 것이 이상적입니다.
레이어를 만드는 데에 있어 top-down 방식은 현재 약간 구식이라고 할 수 있습니다. 하지만 여기에 언급된 4개의 레이어는 다른 현대 아키텍처에 충분히 적용될 수 있는 것들입니다. 레이어드 아키텍처는 가장 단순하며, 아키텍처를 배우기에 가장 좋은 방법입니다.
