.png%3Ftable%3Dblock%26id%3Db06785f0-5ea3-4b47-9323-3ae8cf4b0e26%26cache%3Dv2&w=3840&q=75)
클린 아키텍처(Clean Architecture)란?
클린 아키텍처는 소프트웨어 시스템의 설계에 관한 원칙과 방법을 정의한 개념입니다. 로버트 C. 마틴이 소개한 이 아키텍처는 복잡한 소프트웨어 시스템을 보다 효과적으로 관리 가능하고 유지 보수 가능한 형태로 구축하기 위한 지침을 제공합니다.
이 아키텍처는 소프트웨어의 유지 보수성과 테스트 용이성을 강조하며, 모듈 간의 분리를 중시합니다. 이를 통해 안드로이드 애플리케이션을 보다 구조화된 방식으로 개발할 수 있도록 도와줍니다.
클린 아키텍처는 소프트웨어를 계층화하고 각 계층 간의 의존성을 최소화하여 시스템을 유연하고 테스트하기 쉽도록 만듭니다. 이를 위해 의존성 역전 원칙(Dependency Inversion Principle, DIP)과 같은 원칙을 따르며, 테스트 용이성, 도메인 중심 설계, 프레임워크 독립성 등의 특징을 가지고 있습니다.
클린 아키텍처가 유행하게 된 배경
클린 아키텍처는 소프트웨어 시스템을 다양한 독립적인 구성 요소로 분리하는 것을 강조하여 시스템을 더 쉽게 유지보수할 수 있도록 합니다.
모듈화는 클린 아키텍처에서 중요한 개념으로, 시스템의 각 부분을 모듈화하여 테스트와 유지보수를 용이하게 만듭니다.
또한, 클린 아키텍처는 시스템의 기술과 요구사항의 변화를 수용할 수 있는 확장 가능한 설계를 제공하여 시스템을 더 유연하게 만듭니다.
재사용성을 강조함으로써 여러 시스템에서 재사용 가능한 컴포넌트를 만들 수 있습니다. 이는 개발자가 다른 소프트웨어나 기능을 개발할 때 필요한 시간과 노력을 줄여줍니다.
또한, 클린 아키텍처의 개념은 단순하고 이해하기 쉬우며, 이로 인해 많은 개발자와 IT 스타트업들이 도입하고 있습니다. 이는 클린 아키텍처가 현재의 소프트웨어 개발 트렌드로 이어지게 한 주요한 이유 중 하나입니다.
클린 아키텍처의 주요 원칙
계층화와 안정성
원의 안쪽에는 변경되지 않는 핵심 기능을 위치시키고, 바깥쪽으로 갈수록 변경될 가능성이 높은 부분을 배치합니다. 이렇게 함으로써 변경이 발생했을 때 영향을 최소화할 수 있습니다.
외부 영역은 내부 영역에 의존할 수 있지만, 내부 영역은 외부 영역에 의존하지 않음
외부 영역(예: 인터페이스, UI, 프레임워크)은 내부 영역(예: 비즈니스 로직, 엔티티)에 의존할 수 있지만, 그 역은 성립하지 않아야 합니다. 이를 통해 각 계층 간의 의존성이 줄어들고 역할이 명확해집니다.
프레임워크에 의존하지 않음
클린 아키텍처는 비즈니스 로직이 프레임워크에 의존하지 않도록 설계되어야 합니다. 프레임워크는 도구에 불과하며 비즈니스 로직이 프레임워크에 의해 제어되면 안 됩니다.
유스케이스(UseCases)는 아키텍처에서 최우선
UseCases는 핵심 비즈니스 로직을 담당하므로 아키텍처에서 우선적으로 고려되어야 합니다. 클린 아키텍처를 사용하면 프레임워크나 외부 환경 없이도 유스케이스에 대한 테스트가 가능해야 합니다.
헥사고날 아키텍처란?
포트와 어댑터 아키텍처, 또는 헥사고날 아키텍처는 인터페이스나 기반 요소의 변경에 영향을 받지 않는 핵심 코드를 만들고 이를 견고하게 관리하는 것을 목표로 합니다. 이를 통해 애플리케이션의 핵심 기능을 유지하면서 외부 요구사항에 유연하게 대응할 수 있습니다.
예를 들어, 개발자가 Command Line Interface(CLI)를 통해 간단한 기능을 제공하는 애플리케이션을 개발했다고 가정해봅시다. 그러나 동료 개발자들이 웹 인터페이스를 추가해야 한다고 제안합니다. 개발자는 포트와 어댑터 아키텍처를 사용하여 애플리케이션의 핵심 로직을 변경하지 않고도 새로운 인터페이스를 추가할 수 있습니다. 이로써 새로운 기능을 구현하기 위해 코드 대부분을 수정할 필요가 없습니다.
또한, 애플리케이션의 영속성 관리 시스템을 변경해야 한다면 어떨까요? 초기에는 파일 시스템을 사용했지만, 점점 관리가 어려워지면서 MySQL로 전환해야 할 필요성이 생겼습니다. 포트와 어댑터 아키텍처를 사용하면 이러한 변경에도 핵심 로직의 수정이 거의 없이 적용할 수 있습니다.
이처럼 포트와 어댑터 아키텍처를 적용하면 애플리케이션의 핵심 로직은 변경 없이 외부 요구사항에 쉽게 대응할 수 있습니다. 이는 애플리케이션의 유연성과 확장성을 높이고, 유지보수 비용을 줄이는 데 도움이 됩니다.
헥사고날 아키텍처의 구성
헥사고날 아키텍처는 내부(도메인)와 외부(인프라)로 구분됩니다.
내부 영역은 순수한 비즈니스 로직을 표현하며 캡슐화된 영역입니다. 이 영역은 기능적 요구사항에 따라 먼저 설계되며, 비즈니스 도메인의 핵심 로직을 포함합니다. 여기서는 비즈니스의 규칙과 프로세스를 구현하고, 데이터 처리 등의 핵심 기능을 처리합니다.
외부 영역은 내부 영역에서 기술을 분리하여 구성한 영역입니다. 내부 영역 설계 이후에 설계되며, 외부 시스템과의 상호작용, 데이터베이스 접근, UI 등과 같은 기술적인 요소들을 담당합니다. 이 영역은 외부 시스템과의 통합, 데이터베이스 접근을 담당하며, 내부 영역의 변경에 영향을 최소화하기 위해 외부 시스템과의 결합을 낮춥니다.
포트와 어댑터란?
포트와 어댑터는 소프트웨어 아키텍처에서 중요한 개념으로, 인터페이스와 그 인터페이스를 구현하는 부분을 나타냅니다. 여기서 "포트"는 외부와의 인터페이스를 나타내며, "어댑터"는 내부의 구현을 외부 인터페이스에 맞추기 위한 역할을 합니다.
예를 들어, 책이나 DVD를 대여하고 반납하는 애플리케이션을 구현한다고 가정해봅시다. 이 애플리케이션에서는 대여 및 반납 기능을 외부에서 호출할 수 있는 인터페이스가 필요합니다. 이것이 바로 "포트"입니다. 이러한 포트는 일반적으로 애플리케이션의 핵심 비즈니스 로직을 호출하는 역할을 합니다.
이제, 이 포트를 호출하여 실제로 대여와 반납을 처리하는 내부 로직이 필요합니다. 이 내부 로직을 구현하는 것이 바로 "어댑터"입니다. 어댑터는 외부 인터페이스와 내부 로직 간의 중간 다리 역할을 하며, 외부에서 호출 가능한 인터페이스를 내부 로직에 맞게 변환하여 처리합니다.
예를 들어, 대여 기능을 호출하는 외부 인터페이스(포트)는 "대여" 메서드를 호출할 것입니다. 이를 처리하기 위해 대여 도서의 정보를 데이터베이스에서 가져오고 대여 기록을 저장하는 내부 로직이 필요합니다. 이러한 내부 로직을 수행하는 어댑터가 바로 "어댑터"입니다.
이렇게 포트와 어댑터를 사용하면 외부와 내부 간의 인터페이스를 분리하여 시스템을 더 유연하게 만들고, 변경에 용이하게 합니다.
import { Injectable, NotFoundException } from '@nestjs/common'; import { CustomerRepository } from './customer.repository'; import { RentalRepository } from './rental.repository'; import { InventoryService } from './inventory.service'; import { RentalHistoryRepository } from './rental-history.repository'; import { RentalTarget } from './rental-target.interface'; import { RentalHistory } from './rental-history.model'; import { Rental } from './rental.model'; import { Item } from './item.model'; import { RentalSpec } from './rental-spec.model'; import { AlreadyRentedException } from './already-rented.exception'; import { v4 as uuidv4 } from 'uuid'; @Injectable() export class TotalRentalService { constructor( private readonly customerRepository: CustomerRepository, private readonly rentalRepository: RentalRepository, private readonly inventoryService: InventoryService, private readonly rentalHistoryRepository: RentalHistoryRepository, ) {} async rent(target: RentalTarget): Promise<RentalHistory> { const borrower = await this.customerRepository.find(target.customerId()); if (!borrower) { throw new NotFoundException(target.customerId()); } const rental = await this.rentalRepository.find(target.rentalId()); if (!rental) { throw new NotFoundException(target.rentalId()); } const rentedItem = await this.inventoryService.rent(rental, borrower); if (!rentedItem) { throw new AlreadyRentedException(); } const history = RentalHistory.of( uuidv4(), RentalSpec.of(borrower, rental), rentedItem, ); await this.rentalHistoryRepository.save(history); return history; } }
이 서비스는 TotalRentalService를 구현하여 RentalHistory rent(RentalTarget)라는 인터페이스를 제공하고 있습니다. 이 서비스는 MVC 패턴을 채택했다면 컨트롤러에서 사용됩니다. 컨트롤러는 HTTP를 통한 인터페이스를 클라이언트에게 제공하여 클라이언트가 TotalRentalService를 이용할 수 있도록 중간 역할을 합니다.
아래 그림은 이러한 구조를 나타내는데요.
+-------------------+ +---------------------+ +------------------+ | | HTTP | | Usage | | | Client +------------>+ Controller +----------->+ TotalRentalService| | | Request | | Total | | +-------------------+ +---------------------+ Service +------------------+ | | | Business Logic | | | +---------------------+
Client는 HTTP 요청을 Controller에 보내고, Controller는 해당 요청을 TotalRentalService로 전달합니다. TotalRentalService는 비즈니스 로직을 수행하고, 결과를 Controller로 반환합니다. Controller는 다시 클라이언트에게 HTTP 응답을 전송하여 처리 결과를 제공합니다. 이를 통해 클라이언트는 TotalRentalService의 기능을 HTTP 인터페이스를 통해 사용할 수 있습니다.
TotalRentalService의 구현체는 내부적으로 CustomerRepository나 RentalRepository, InventoryService 인터페이스를 사용합니다. 만약 Repository가 데이터의 영속을 위해 Redis를 사용한다면 아래 그림과 같이 표현할 수 있습니다.
+------------------+ | | | TotalRental | | Service | | | +--------+---------+ | +------------+------------+ | | | CustomerRepository | | | +------------+------------+ | +------------+------------+ | | | RentalRepository | | | +------------+------------+ | +------------+------------+ | | | InventoryService | | | +------------+------------+ | +------------+------------+ | | | RedisRepository | | (Adapter for Redis) | | | +------------------------+
아래 그림에서 Repository와 Service 인터페이스는 TotalRentalService가 사용하는 포트를 제공합니다. 예를 들어, 코드 스니펫에서 rentalRepository.find()나 inventoryService.rent()와 같은 메서드가 이를 보여줍니다. 추가적으로, Repository가 Redis와 통신하기 위해 특정 프로토콜을 사용한다면, RedisRepository와 같은 구현체가 있을 것입니다. 이 구현체는 Repository 인터페이스를 따르면서 내부적으로 Redis 프로토콜과 연결됩니다. 이러한 포트와 어댑터는 애플리케이션이 호출될 때 동작하며, 이를 부요소(secondary)라고 합니다. 이들은 부포트 또는 부어댑터라고도 불릴 수 있습니다.
아래는 포트와 어댑터 아키텍처를 따른 소프트웨어와 인터페이스, 기반 요소와의 관계를 자세히 설명한 그림입니다.
+-----------------------+ +------------------------+ +------------------------+ | | | | | | | Client +--------->+ Controller +---------->+ TotalRentalService | | | Request | | Usage | | +-----------------------+ +------------------------+ Total +------------------------+ | +------------+-------------------------+--------------------------+ | | | | | | | CustomerRepository | RentalRepository | | | (Customer Data Storage) | (Rental Data Storage) | | +------------+-------------------------+--------------------------+ | | +------------+-------------------------+--------------------------+ | | | | | | | InventoryService | RedisRepository | | | (Inventory Management Service) | (Adapter for Redis) | | +------------+-------------------------+--------------------------+ | | +------------+-------------------------+------------------------------+ | | | | | HTTP | RPC | MySQL | | Adapter | Adapter | Adapter | | | | (Adapter for MySQL) | +------------+-------------------------+------------------------------+
이 그림에서, Client는 HTTP Request를 생성하여 Controller로 보냅니다. Controller는 TotalRentalService의 인터페이스를 사용하여 비즈니스 로직을 호출합니다. TotalRentalService는 CustomerRepository, RentalRepository, InventoryService와 같은 다양한 포트를 사용하여 데이터 및 서비스에 접근합니다.
각 포트에는 하나 이상의 어댑터가 있습니다. 이러한 어댑터는 실제 데이터 저장소나 서비스와 통신하며, 필요에 따라 데이터를 변환하거나 처리합니다. 예를 들어, RedisRepository는 Redis와 통신하기 위한 어댑터로, MySQL을 사용하는 경우에는 MySQL과 통신하기 위한 어댑터가 될 것입니다.
또한, 주요 기반 요소인 HTTP 및 RPC는 각각 HTTP Adapter 및 RPC Adapter와 같은 어댑터를 통해 애플리케이션과 통신합니다. 마찬가지로, MySQL을 사용하는 경우에는 MySQL Adapter가 필요합니다.
이러한 구성은 포트와 어댑터 아키텍처를 통해 애플리케이션의 비즈니스 로직과 외부 기반 요소 간의 결합을 최소화하고, 유연성과 확장성을 향상시킵니다.
헥사고날 아키텍처의 장점
메인 비즈니스 모델에 집중
헥사고날 아키텍처는 DIP를 통해 의존성이 도메인에서 밖으로 나가는 부분이 없으므로 외부 요소를 신경쓰며 개발할 필요가 없습니다. 이는 개발자들이 도메인 비즈니스 모델에 집중할 수 있도록 돕습니다.
모듈 일부를 배포하는 게 용이
기술과 실제 비즈니스 로직의 분리, 각 도메인 별 비즈니스 로직 분리를 통해 느슨한 결합을 가져가기 때문에 특정 모듈만을 배포하는 것이 용이합니다.
기능 확장이 용이
필요한 기능에 대한 포트와 해당 포트를 사용할 어댑터를 추가함으로써 기능을 확장할 수 있습니다. 이는 새로운 기능 추가나 기존 기능 변경이 상대적으로 간단하게 이루어질 수 있음을 의미합니다.
쉬운 테스트 구성
외부 기술들은 포트를 통해 비즈니스 로직과 연결되기 때문에, 필요한 포트만을 사용하여 모킹 어댑터를 통해 테스트를 쉽게 수행할 수 있습니다. 또한 내부 비즈니스 로직을 테스트할 때 외부 의존성이 없기 때문에 모킹이 적게 필요합니다.
개발 비용 감소
계층간 의존성이 낮아지고 유연성이 높아지기 때문에 요구사항에 빠르게 대응할 수 있고, 테스트도 쉽게 적용할 수 있습니다. 이는 개발 비용을 감소시키고 효율성을 높입니다.
SoC(관심사 분리)의 장점
외부 연결에 문제가 생기면 어댑터를 확인하고, 인터페이스의 정의를 변경하고자 한다면 포트를, 비즈니스 로직이 제대로 동작하지 않는다면 도메인 로직만 확인하면 되므로 효율적인 관심사 분리가 가능합니다.
헥사고날 아키텍처의 단점
코드가 많아짐
도메인 계층이 영속성, UI 등과 엄격하게 분리되어야 하므로 각 계층에서 엔티티 모델을 유지보수해야 합니다. 예를 들어, ORM 프레임워크는 DB 구조 및 객체 필드 간의 매핑을 정의하는 메타데이터를 포함한 엔티티 클래스를 요구합니다. 그러나 도메인 계층은 영속성 계층을 알지 못하기 때문에 두 계층에서 각각의 엔티티를 생성해야 하며, 이로 인해 데이터를 주고받을 때 두 엔티티를 서로 매핑해야 합니다. 이와 같은 매핑 과정은 도메인 계층과 다른 계층 간에도 반복됩니다.
불필요한 오버헤드
헥사고날 아키텍처를 도입하기 위해서는 포트, 어댑터 등의 개념을 이해해야 하며, 이를 구현하기 위해서는 인터페이스인 포트를 정의해야 합니다. 또한 도메인 모델의 여러 표현 사이를 매핑하는 객체를 생성해야 합니다. 이러한 추가 작업은 초기에는 번거로울 수 있습니다.