JangBaGeum.gif

썸네일하고 본 글의 주제는 관련이 없습니다. '◡'✿ 나는 현업에 애플리케이션 구조를 설계할 때 가장 흔하면서 단순한 레이어드 아키텍처 Layerd Architecture를 많이 사용해 왔다.최근에 MSA Microservice Architecture를 공부하면서 접한 헥사고날 아키텍처 Hexagonal Architecture 패턴을 실무에 적용해 보면서 꽤나 긍정적인 경험을 했다. 이번 글에서는 헥사고날 아키텍처를 간단히 소개하면서 작고 소중한 내 작품에 실제로 적용하고 느낀 레이어드 아키텍처와의 차이점, 그리고 장점을 적어보려고 한다.  1. 헥사고날 아키텍처란 Hexagonal Architecture 헥사고날 아키텍처는 Alistair Cockburn(애자일 방법론을 제시한 인물 중 1인)이 제한한..

개발을 하다 보면 외부 API를 수없이 사용하게 되고 고려하지 않으면 요청한 API 서버로부터 `429 Too Many Request`라는 곤란한 응답을 받게 된다. Rate Limting은 API Client만 고민하는 것이 아닌 요청을 받고 응답을 내려주는 API Server로부터 고려된 것이고 API Server는 DoS 공격과 같은 공격에 대해 대비하고 서버의 응답 처리량을 관리하기 위해서는 Rate Limiting은 필수로 고려되어야 하는 부분이다. 나는 얼마 전에 429 응답을 마주하게 되었고 요청을 받는 입장이 아닌 요청을 하는 입장에서 어떻게 요청량을 관리해야 될지에 대한 방법론을 몇 가지 알아보려고 한다. (Server와 Client의 방법론은 크게 다를 것 없다.) 429 Too Man..

새로운 프로젝트를 시작하면서 구현만을 하던 API서비스를 직접 설계하게 되는 기회가 생겼다. 지속적으로 유지 관리가 되어야 하며 확장의 계획이 있는 프로젝트이기에 확실한 기반과 구조를 가져가야 했고, 이번 기회에 API설계에 대한 패턴을 탐색해 보았다. API 설계 패턴은 빠른 확장을 가능하게 하고 설계 및 구동에 있어 일반적인 문제를 해결하는데 청사진이 될 수 있다. 하기 내용에는 API 디자인 패턴의 사용 이점과 일반적인 패턴, 구현 모범 사례를 함께 다루어 보려고 한다. API 디자인 패턴을 사용하면 좋은 점 디자인 패턴을 사용하는 원초적인 이유는 협업의 용이성과 안정적인 서비스 운용 등 다양하게 있다. 이에 따라서 API 디자인 패턴을 사용하면 함께 협업하는 개발자와 API를 더 쉽게 이해하고 확..

DTO Data Transfer Object)는 애플리케이션 간에 테이터의 전달을 목적으로 하는 객체이다. 이는 프레젠테이션 계층과 비즈니스 계층, 혹은 비즈니스 계층과 데이터 액세스 계층, 더 나아가 애플리케이션 간에서 비즈니스 로직을 갖지 않고 순수하게 데이터 전송을 위해 사용된다.  클라이언트와 서버의 관계를 갖는 서비스를 설계/구축해 봤으면 누구나 DTO에 대한 개념을 알 것이다. 그러나 순수한 DTO의 의미와 의도를 정확히 파악하고 구현하는 것은 어려움이 있을 것이라 생각된다.  최근 서비스를 구현하면서 DTO/VO/Entity 등 데이터를 다루는 기본적인 객체에 대해 고민을 해보면서, 더 정확히 알고 쓰면 깔끔하면서 명확한 코드 작성이 가능할 것 같아 몇 가지 알아본 내용을 정리해보려고 한다...

현재 업무는 함수형 프로그래밍을 지향하다 보니 함수들만 주야장천 찍어냈습니다. 그러던 중 오랜만에 필요에 의해 클래스를 작성하게 되었고 싱글톤 패턴을 적용을 해보는 기회가 되었습니다. 이론으로만 보던 싱글톤 패턴을 보니 반갑기도 하고 해서 간단히 서칭 한 내용을 정리해보려고 합니다. 싱글톤 패턴 singleton pattern이란? 애플리케이션에서 하나의 인스턴스만을 생성하고, 이를 전역적으로 사용하는 디자인 패턴 싱글톤 패턴은 객체지향 디자인 패턴 중 하나로, 어떤 클래스의 인스턴스가 오직 하나만 만들어져야 하는 상황에서 사용됩니다. 이 패턴을 사용하면 인스턴스를 여러 개 만들어서 발생할 수 있는 문제를 방지할 수 있습니다. 인스턴스를 여러 개 만들면 발생할 수 있는 문제 인스턴스를 여러 개 만들어서 ..

회사 내의 코드베이스를 검토하다 보면 과도하게 분산되어 있는? 성향이 조금 있는 것 같아(사실은 그냥 정리가 안된 거일 수도,,,) 과연 옳은 방법으로 코드들이 관리되는 것인가 고민을 한 적이 있습니다. 회사 내 서비스 특성상 하나의 서비스지만 버전이 여러 개로 나뉠 수밖에 없는 구조이지만 분명 하나로 통일 할 수 있는 방법이 있을 것이고 각자 관리됨에 있어 항상 컨벤션 검토를 거쳐야 되는 번거로움도 해결이 가능할 것이라고 생각했습니다. 예전부터 MSA(Microservices Architecture)가 인기이면서 회사 내에서도 지향하는 듯한 느낌이긴 한데, 과도하게 늘어나는 관리 포인트와 가지각색의 컨벤션은 가장 먼저 해결해야 되지 않을까 싶습니다. 찾아보니 꼭 분산만 지향하는 쪽으로 개발 방법론만 있..