학습하면서 작성한 글입니다. 잘못된 부분이 있으면 지적해주시면 감사하겠습니다.
1. 클린 아키텍처란
- 모듈화와 의존성 분리를 강조하는 아키텍처 패턴으로 각 구성요소를 엄격하게 분리하고 의존성을 내부로 향하게 하여 높은 유연성과 확장성에 목적을 둔 아키텍처입니다.
- 관심사를 분리해 의존도를 낮춰 유지보수를 하기 쉽게 만들고 재사용성을 높일 수 있습니다.
(관심사를 분리한다는 것은 프로그램을 목적에 맞게 분리한다는 말입니다.)
2. 클린 아키텍처의 구조
출처: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
- 화살표의 방향은 의존성을 의미하며 의존성은 밖에서 안으로 향합니다.
- 안쪽 원은 본인보다 바깥쪽의 원은 모르며 바깥쪽의 어떤 것도 참조해서는 안됩니다.
- 바깥쪽의 영역은 안쪽에 영향을 미치지 않으며 안쪽부터 고수준 정책, 바깥쪽으로 갈수록 저수준 정책을 의미합니다.
(고수준: 추상화된 개념, 저수준: 추상화된 개념의 실제 구현에 대한 세부적인 개념 고수준: "게임을 한다", 저수준: "집에서 취미로 게임을 한다"로 풀어서 설명할 수 있습니다.)
엔티티 (Entities)
- 핵심 비즈니스 규칙을 포함하는 객체로, 주로 도메인과 비즈니스 모델로 표현됩니다.
- 도메인 계층으로도 불리며 변경될 가능성이 가장 적은 부분이고 외부로부터 영향을 받지 않는 영역입니다.
유즈케이스 (Use Cases)
- 엔티티를 활용하여 비즈니스 규칙을 구현하고 데이터 처리를 수행합니다.
- 애플리케이션 계층으로도 불리며, 이 영역의 변경사항이 엔티티에 영향을 주어서는 안되고, 외부 프레임워크에 의해 영향을 받아서도 안됩니다.
- 비즈니스 로직을 담당하는 서비스(Service)로 표현합니다.
인터페이스 어댑터 (Interface Adapters)
- 외부 프레임워크에서 들어오는 데이터를 엔티티와 유즈케이스가 처리하기 쉬운 형태로 변환하고, 반대로 엔티티와 유즈케이스에서 나가는 데이터를 외부 프레임워크에서 처리하기 편한 형태로 변환합니다.
- 컨트롤러, 게이트웨이, 프레젠터 등이 있습니다.
프레임워크와 드라이버 (Frameworks & Drivers)
- 인프라 계층으로도 불리며, 외부 요소들과의 연결을 관리하고 상대적으로 변경이 잦은 부분입니다.
- 프레임워크, DB, Web, UI 등이 있습니다.
3. 왜 필요할까?
예를 들어 설명하겠습니다. 여러분이 A 배달 앱의 개발자이며, 어느 날 A 배달 앱이 B 배달 앱과 통합된다고 가정하겠습니다. 이때 여러분은 다음과 같은 요구를 받게 됩니다.
“A 배달 앱 시스템이 잘 되어 있으니 A 앱의 핵심 기능은 유지하고, UI와 DB 쪽만 바꿔 주세요.”
또는 다음과 같은 요구를 받을 수도 있습니다.
“A 배달 앱이 너무 잘되니 서비스를 웹으로 확장해 봅시다.”
비즈니스의 로직은 비슷한데, 변경해야 하는 부분도 많고, 아예 새로 만들 수도 없는 이러한 상황이라면, 여러분은 어떻게 하실 건가요?
만약 클린 아키텍처를 도입했다면, 단순하게 인터페이스 어댑터 영역과 프레임워크와 드라이브 영역만 수정하면 됩니다. 왜냐하면 ‘고객과 업체 사이에서 배달 서비스를 중계한다’는 비즈니스 로직은 변하지 않았기 때문입니다. 이와 같이 클린 아키텍처는 비즈니스 로직은 바꾸지 않으면서, 언제든 DB와 프레임워크에 구애 받지 않고 교체할 수 있는 아키텍처인 셈입니다.
출처: https://meetup.nhncloud.com/posts/345
참고한 글 중에 이 질문에 대한 깔끔한 설명이 되어있는 부분을 가져와 보았습니다.
클린 아키텍처의 영역 구분과 의존성 규칙을 이용하여 높은 유연성과 확장성을 통해 수정할 부분이 크게 줄어들었습니다. 또한 유지보수성 향상으로 UI와 DB를 변경하더라도 핵심 비즈니스 로직은 수정하지 않아도 됩니다.
4. 가장 중요한건 의존성 규칙
클린 아키텍처의 4개 영역은 상황에 따라 적절히 수정하여 사용할 수 있습니다. 가장 중요한건 항상 밖에서부터 안쪽으로 향하는 의존성 규칙을 지키는 것입니다.
참고
1년차 Java&Spring 백엔드 개발자입니다!