Architecture

비즈니스 로직(Service layer)의 역할

개발자로 일을 하다 보면 개발에 관련된 모든 것들은 추상화로 이루어져 있다는 생각이 들 때가 있다. 결국 개발 언어나 라이브러리, 프레임워크 전부 다 내부적으로 어떻게 구동되는지는 몰라도 결과값을 유추할 수 있고 해당 결과값들의 집합으로 완성된 서비스를 만들 수 있다. 서비스를 구현할 때 좋은 구조의 설계를 하기 위해 역할과 책임에 따라서 계층을 나누게 된다. 보통 3계층 아키텍처를 많이 사용하는데 구조는 아래와 같다. 1. 비즈니스 로직 비즈니스 로직은 서비스의 핵심 로직이라고 생각하기 때문에 Service 계층에서 구현하고 다른 계층의 문제가 전파되지 않게 아키텍처 설계를 하고 있다. 1-1. Service 계층에서의 의존성 회사에서 개발할 때 Service 계층에선 Repository 계층을 의존..

AWS Lambda - SQS를 활용한 인프라 아키텍처 재설계 ( + S3, 맥미니?)

1. 갖고 있던 문제 자세히 말할 수는 없지만 회사에 그래픽카드가 필요한 컨버팅 서버가 있었다. 해당 서버는 AWS EC2에서 그래픽 카드가 있는 맥서버로 배포되어 있었는데 큰 문제가 있었다. 바로 월 100만 원가량의 비싼 비용과 트래픽에 취약하다는 문제였다. 해당 서버를 배포한 동료직원의 얘기를 들어보면 컨버팅에 필요한 프로그램을 돌리는데 필요한 최소조건의 서버를 빌렸다고 했기 때문에 사양을 낮춰서 금액을 줄이는 방법은 사용할 수가 없었다. 그리고 http통신으로 컨버팅에 필요한 정보를 받아오는 구조였는데 트래픽에 대한 대비가 전혀 없어 위험했고, 오토스케일링으로 스케일 아웃을 적용하려고 해도 비싼 비용이 너무 부담되는 상황이었다. 2. 인프라 아키텍처 재설계 회사에서도 해당 서버 비용에 대한 부담이..

헥사고날 아키텍처(포트 앤 어뎁터 아키텍처)_Express example

클린 아키텍처 클린 아키텍처가 갖는 기본적인 목적은 관심사의 분리다. 각각 계층별로 관심사를 나누고, 도메인 (비즈니스 로직) 중심으로 설계해야 한다. 또한 프레임워크나 외부 UI에 의존하지 않아야 한다. 헥사고날 아키텍처 (포트 앤 어뎁터 아키텍처) 헥사고날 아키텍처는 클린 아키텍처와 거의 비슷하다. 둘은 도메인 (비즈니스 로직)을 인프라 (단순히 AWS와 같은 인프라 뿐만 아니라 view layer와 도 포함)에서 분리하는 것이다. → 위 그림은 클린 아키텍처 그림이다. 엔티티가 가장 안쪽에 있고, 의존성은 밖에서 안쪽으로만 존재한다. 그렇기 때문에 엔티티에 접근하기 위해선 계층을 전부 거쳐야 들어올 수 있다. → 해당 그림은 헥사고날 아키텍처의 그림이다. 클린아키텍처 그림과 동일하게 의존성은 밖에서..