목적, 수단, 목표

프론트엔드를 위한 백엔드, Backends For Frontends(BFF) 시간이 지나면서 서비스가 제공하는 프론트 엔드의 코드가 점점 더 복잡해지고 다양해지는 경우는 허다하다. 이에 따라 백엔드 또한 기능 제공을 위해 복잡해지게 된다. 따라서 다양한 프론트엔드 유형의 기능을 지원하는 백엔드 서비스가 필요성이 생겨나게되었고, 이를 위해 BFF 가 탄생하게 되었다. 웹 서비스만 제공하던 서비스에서 모바일 서비스를 제공해야하는 경우, 새로운 유형의 프론트엔드를 도입해야한다.(모바일기기의 성능과 데스크톱의 성능이 다르기 때문) 새로운 서비스(모바일)을 제공하기 위해서는 백엔드에서도 모바일에 특화된 코드와 기능을 추가해야한다. 모바일 기기는 화면 크기가 더 작으므로, 기존의 API가 아닌 새로운 API 를 통..

파이프-필터 아키텍처(Pipes and Filters Architecture) 파이프-필터 아키텍처는 일련의 파이프를 따라 흐르며 여러 단계의 필터를 통과해 원하는 환경에 도달하는 데이터로 묘사할 수 있다. 파이프 는 필터를 연결하며, 일반적으로 분산 대기열이나 메시지 브로커에 해당한다. 필터는 각 단계에서 데이터를 처리하는 고립된 소프트웨어 컴포넌트 에 해당하며, 수신 데이터에 대해 하나의 작업만을 수행하고, 나머지 파이프라인과 무관하게 동작한다. 데이터 소스: 데이터의 출처를 말한다. 사용자로부터 네트워크 요청을 수신하는 백엔드 서비스가 될 수도 있다. 센서 또는 종단 장치에서 데이터 샘플을 수신하는 서비스형 함수 요소 같은 경량 서비스가 될 수 있다. 데이터 싱크: 모든 처리 단계(필터)를 통과한 ..

로드밸런싱, LoadBalancing 로드밸런싱이란, 전송자로부터 오는 각 요청을 시스템 내 한 워커에 디스패칭 하는 기능을 말한다. 이를 활용한다면, 사실상 무한대의 컴퓨터 자원을 활용할 수 있는 클라우드 환경에서 손쉽게 확장성을 가진 애플리케이션을 만들 수 있다. 로드밸런싱을 사용한다면 매일 수십억 개 이상의 요청을 처리할 수 있다. PB 규모의 데이터를 처리할 수 있다. 클라우드 환경에서 비용 효율적인 아키텍처를 구축할 수 있다. 로드밸런싱이 없을 경우 수만 명의 고객이 사용하는 애플리케이션을 단일 클라우드 서버 에서 배포하는 상황일 경우 다음과 같은 문제점이 발생할 수 있다. 수신 트래픽이 단일 서버의 CPU 메모리 혹은 네트워크 용량을 넘어설 경우 애플리케이션이 충돌하거나 성능이 저하될 수 있다..

코드의 디커플링 소프트웨어 설계와 개발 과정에서 코드의 복잡성은 가독성과 유지보수성 과 연관이 있기 때문에 우리는 코드의 복잡성을 제어해야한다. 그리고 코드의 복잡성을 제어하는 가장 효과적인 방법은 디커플링이다. 디커플링을 통해 응집도가 높고 결합도가 낮은 코드를 만들 수 있다. 높은 응집도와 낮은 결합도 높은 응집도와 낮은 결합도는 클래스 간의 세분화된 관계 설계를 이끌어 낼 뿐만아니라 세분화된 시스템, 아키텍처, 모듈의 설계를 이끌어내는 일반적인 사상이다. 코딩 규칙에 비하여 더 높은 수준에서 코드의 가독성과 유지보수성을 향상 시킬 수 있다. 높은 응집도 와 낮은 결합도 의 특성을 활용한다면, 다른 모듈이나 클래스 코드에 대해 너무 많이 이해할 필요 없이 모듈이나 클래스에 집중할 수 있다. 의존성 이..

포스팅에서의 클린아키텍처는 Ports and Adapters 아키텍처, 헥사고날 아키텍처(육각형 아키텍처) 모두 같은 것을 의미한다. 클린 아키텍처는 도메인 중심의 아키텍처에 적합하기 때문에 도메인 엔터티를 만드는 것으로 시작한 후, 해당 도메인 엔터티를 중심으로 유스케이스를 구현한다. 엔터티에는 비즈니스 업무 규칙이 존재한다. 유스케이스는 엔티티를 감싸고 있다. 유스케이스는 애플리케이션에 특화된 업무 규칙(비즈니스 규칙)을 표현하며, 엔티티 내부의 핵심 업무 규칙을 호출(도메인에 접근)하고 시스템을 사용하는 흐름을 담는다. 엔티티(고수준영역)은 유스케이스영역(저수준영역)을 알게 해서는 안됨에 주의한다. 엔터티는 간단한 객체여야 하며, 프레임 워크 데이터베이스 또는 기타 복잡한 것에 의존해서는 안되고 유..

포스팅에서의 클린아키텍처는 Ports and Adapters 아키텍처, 헥사고날 아키텍처(육각형 아키텍처) 모두 같은 것을 의미한다. 이번 포스팅에서는 지난 포스팅에서이야기한 클린 아키텍처(Ports and Adapter) 의 구성과 이를 반영한 프로젝트의 패키지 구조에 대해 이야기를 해보려고한다. 참고 포스팅 [아키텍처] 클린아키텍처(Ports and Adapters): 왜 클린 아키텍처를 공부하게 되었는가? 왜 클린 아키텍처를 공부하게 되었는가? 나는 모놀리식 아키텍처, 계층형 아키텍처(MVC) 기반의 개인 프로젝트와 짧지만, 레거시 프로젝트를 담당해 개발한 경험이 있다. 그리고 프로젝트를 개발 sykeem.tistory.com 클린아키텍처에서 가장 중요한 것은 의존성 규칙이다. 모든 계층 간 의존성..

왜 클린 아키텍처를 공부하게 되었는가? 나는 모놀리식 아키텍처, 계층형 아키텍처(MVC) 기반의 개인 프로젝트와 짧지만, 레거시 프로젝트를 담당해 개발한 경험이 있다. 그리고 프로젝트를 개발하는데 있어 나는 코드적인 기준(가독성)을 충족하고 빠르고 쉽게(=낮은 개발 비용)으로 개발을 하고싶었다. 하지만 기존의 계층형 아키텍처의 구조상 이는 쉬운 일이 아니었다. 계층형 아키텍처(Layered Architecture) 계층형 아키텍처의 내부 컴포넌트는 수평한 계층(Layer)으로 구성되며, 각 계층은 애플리케이션에서 주어진 역할을 수행하게 된다. 계층형 레이어의 종류에는 프리젠테이션(presentation, 웹 계층), 비즈니스(business, 도메인계층), [퍼시스턴스(persistence) , 데이터베..

나는 프로젝트를 개발하면서, 이것이 최선의 코드일까?의 생각에서 시작하여, 이게 최선의 아키텍처 구조일까? 하는 생각의 확장으로, 좋은 코드를 작성하는 방법에서 부터 코드 수준을 넘어서는 좋은 아키텍처에 많은 관심을 갖게되었다. 그런데 좋은 코드에 대한 예시에 대한 자료는 많이 찾아볼 수 있었는는데, 좋은 아키텍처에 대한 예시는 그렇지 못했다.(하지만 다양한 아키텍처에 대한 많은 공부를 할 수 있었다. 그리고 내가 자료를 잘 찾지 못한 것도 한 몫했을것이다..) 좋은 코드와 좋은 아키텍처는 많은 개발을 진행경험하고 다양한 문제를 직면서하면서 점점 구체화되고 생성되어진 것 같다. 좋은 코드, 좋은 아키텍처는 무엇일까? 나는 개발이 그렇듯, 정답은 없지만, 오답은 존재한다 생각한다. 그리고 이번 기회를 통해..