이번 BURNIN 프로젝트 아키텍처!(뿌듯해서 가져와봄)
다시 본론으로 돌아가, 백엔드의 코드의 아키텍처에 대해서 알아보도록 하자
코드 구조의 중요성
특별한 코드의 구조없이 한 파일에 모든 코드를 구현하는 것은 코드의 양이 많지 않을 때는 간단하다는 장점,
하지만, 코드의 양이 조금만 많아져도 간단하다는 장점을 잃게됨.
-> 논리적으로 혹은 기능적으로 영역을 구분하여 코드를 관리하는 것이 매우 좋고 중요하며, 코드의 구조를 더 체계적으로 그리고 효율적으로 구현하는 것을 코드의 아키텍쳐 (architecture)라고 함.
코드 아키텍쳐를 구상할 때 아래의 요소들을 염두해야함.
확장성
시스템, 서비스가 커져나감에 따라, 큰 규모를 고려하여 구현해야 함.
재사용성
코드 레벨의 재사용성, 즉 함수나 클래스를 재사용하는 수준의 재사용성보다는 구조적인 재사용성을 의미함.
유지보수 가능성
유지보수가 쉬운 코드를 구현하기 위해서는 구조적으로 로직이 잘 정리가 되고 나뉘어 있어야함.
함수나 클래스 등을 사용하여 코드를 추상화 (abstraction)하고 서로 독립적인 로직을 분리하여 필요한 곳에 적절하게 사용되도록 하는 코드를 구현해야함.
코드의 구조를 구현할 때에도 추상화와 독립적으로 분리하는 것이 중요함.
가독성
말그대로, 어렵고 복잡한 로직을 쉽고, 간단하게 구현할 수 있어야 함.
테스트 가능성
unit test를 하기 쉬운 코드는 추상화 (abstraction)이 잘 되어있고, 한 가지 역할만 하는 코드임.
코드의 구조도 마찬가지로 추상화가 잘 되어있고 담당하는 역할이 잘 나뉘어 있는 구조가 테스트하기 쉬운 구조임.
레이어드 패턴
백엔드 API 코드에 가장 널리 적용되는 패턴 중 하나인 레이어드 (layered) 아키텍처 패턴은 Multi-tier 아키텍처 패턴이라고도 불림
코드를 논리적인 부분, 혹은 역할에 따라 독립된 모듈로 나누어서 구성하는 패턴이며, 각각의 모듈이 서로의 의존도에 따라 층층이 쌓듯이 연결되어서 전체의 시스템을 구현하는 구조.
일반적으로 보통 아래와 같은 3개의 레이어가 존재함.
presentation layer
presentation layer는 해당 시스템을 사용하는 사용자 혹은 클라이언트 (client)와 직접적으로 연결되는 부분.
웹사이트에서는 UI에 해당하고 백엔드 API에서는 엔드포인트 (endpoint)에 해당.
presentation layer에서 API의 엔드포인트들을 정의하고 전송된 HTTP 요청 (request)들을 읽어들이는 로직을 구현.
business layer
business layer는 비즈니스 로직을 구현하는 부분으로, 실제 시스템이 구현해야하는 로직을 구현함.
예를 들면, 미니터 API의 tweet 엔드포인트에서 "tweet이 300자가 넘는 지 확인하여 300자가 넘으면 해당 tweet을 거부해야한다."가 예시.
persistence layer
persistence layer는 데이터베이스와 관련된 로직을 구현하는 부분임.
business layer에서 필요한 데이터 생성, 수정, 읽기 등을 처리하며 실제로 데이터베이스에서 데이터를 저장, 수정, 읽어들이기를 하는 역할.
레이어드 아키텍처의 핵심요소
레이어드 아키텍쳐의 핵심요소는 단방향 의존성으로, 각각의 레이어는 오직 자기보다 하위에 있는 레이어에만 의존함.
presentation layer는 business layer에만 의존
business layer는 persistence layer에만 의존
persistence layer는 business layer, presentation layer에 대해 독립적
관심사의 분리 (separation of concerns)로 각 레이어의 역할이 명확히 구분되어 있음.
presentation layer에는 비즈니스 로직이 전혀 구현되어있지 않음.
비즈니스 로직을 처리하기위해서서 presentation layer에서 business layer의 코드를 호출해서 사용해야함.
business layer에는 데이터베이스 관련 로직이 전혀 구현되어 있지 않음.
데이터베이스 처리를 하기위해서는 persistence layer의 코드를 호출해서 사용해야함.
짱이네요