CS

마이크로 서비스 아키텍처(MSA)가 대체 뭐길래? "마이크로 서비스 아키텍처를 구축해야 되요", "서버를 분리해야한다", "프로젝트 크기가 방대하여 개발이 오래 걸려요" 등 다양한 말로 같은 뜻을 개발자들은 말한다. "마이크로 서비스 아키텍처를 구축해야되요!" 라고 하지만 PO나 기획자에게는 쌓여있는 기획들이 있을 것이고 CS를 담당하고 있는 직원들에게는 운영하는데 필요한 기능들을 기다리고 있을 것이고 데이터 분석가들에게는 분석하는데에 필요한 이벤트나 로그들이 기다리고 있을 것이다. 그래도 이유없는 주장은 없을 것이라는 생각에 일정을 물어보면 생각외로 긴 일정들을 요구하고 안정적으로 운영되고 있는 서비스의 버그나 장애가 발생할 수 있을 것이라고 이야기를 한다. 그런 이야기를 듣다보면 점점 마이크로 서비스..

백엔드 개발자가 가장 자주 하는 업무 중 하나를 꼽으라고 한다면 바로 "API 개발"이라고 이야기할 수 있을 것이다. 우리는 API들을 만들면서 API를 구현하는 비지니스 로직은 많이 공부하고 익혔었지만 API 자체에 대해서 잘 설계하는 것은 고려하지 못한 부분이 종종 있을 것이 있을 것이다. 아래와 같은 상황을 겪어 본적이 있는가? 일부 API는 단 하나의 용도로만 사용할 수 있는 방면, 어떤 API는 검색, 필터 등 유연하게 활용할 수 있다. 그리고 과거에 만들어진 어떤 API는 오랫동안 계속 사용하고 있지만 어떤 API는 최근에 만들었음에도 불구하고 약간의 변경이나 기능이 추가될 때 수정이 어려워 새로운 API를 만들거나 기존 API의 버전을 올려야 하는 상황이 발생한다. 서론이 길었지만 이글은 A..

도메인 주도 설계하기 도메인 주도 개발을 진행할 때 가장 먼저 진행해야되는 것은 도메인 모델과 바운디드 컨테스트를 정의하는 것이이다. 만약 개발 먼저 진행했을 때의 문제점을 아래와 같은 문제점이 발생할 수 있다. 아래와 같은 문제점을 발생하지 않기 위해서는 개발을 먼저 진행하기 전에 도메인 전문가와 함께 설계를 같이 진행해야 한다. 도메인 이해 부족: DDD는 모두가 같은 수준의 도메인 지식을 가지는 것을 추구하고 통일된 유비쿼터스 언어를 사용하여 소통하는 것을 지향한다. 개발을 먼저 시작하면 같이 일하는 팀원 모두가 도메인에 대한 충분한 이해가 부족할 수 있다. 유지보수성 감소: 팀원 모두가 각각 다른 도메인 모델을 개발하면서 서로 간의 간극이 커지고 코드의 유지보수성이 감소하게 된다. 이는 시간이 지..

옵저버란? Observer를 직역하자면 어떤 일을 하는지 지켜보지만 어떠한 행동을 취하지 않는 사람이라는 뜻이다. 옛날에 우리가 많이 했었던 스타크래프트 있던 옵저버라는 유닛 또한 시야를 밝혀주고 아군들에게 공유할 뿐 어떠한 공격도 할 수 없는 유닛이였다. 그렇다면 프로그래밍에서의 옵저버는 무슨 역활을 하고 의미하는 것일까? 뉴스 서비스를 통해 이해하기 처음에는 A사, B사, C사의 외부 API를 받아서 보여주는 기능을 개발하였습니다. 아래와 같은 시스템을 구현해야된다고 했을 때에 옵저버 패턴 형식으로 구현하게 된다면 옵저버 패턴이 어떠한 장점을 가지고 있고 어떠한 상황에 사용해야 되는지 쉽게 알 수 있다. 뉴스 구독 서비스의 구현 뉴스 에이전시 public class NewsAgency { privat..

전략 패턴 결제 플랫폼을 만드는데 카드마다 다른 동작을 사용한다고 정의하고 클래스 다이어그램을 그려보면 아래와 같다. 환불, 포인트 적립은 동일하게 동작하지만 결제만은 다르게 동작한다. 라고 가정한다면 위와같이 슈퍼 클래스를 만들고 결제만 재정의하여 상속하는 구조가 나오게 됩니다. 이렇게 구현한 상태에서 요구사항이 추가되어 할부결제가 추가되었다. 위와같이 할부결제를 카드에 추가한다면 할부가 되지 않는 체크카드와 포인트카드도 할부로 결제가 됩니다. 이러한 문제를 해결하려면 아래처럼 재정의하여 아무것도 하지않는 메서드로 정의하여야 한다. public class CheckCard { @Override public void intsallmentPayment() { } } 이러한 구조로 유지보수하다가 처음 보는 ..

서론 TDD 스터디를 운영하면서 팀원들과의 책 내용을 보면서 따라하기보단 서로 개념을 나누면 좋을 것 같다는 생각에 이와 같이 블로그 글을 정리하는 것으로 더 오래 기억이 남게하기 위해 간단하게 정리를 한 글입니다. 본론 필자는 각각의 테스트를 목록화를 시키면서 다음과 같이 테스트를 진행을 하게 되는데 살펴보자면 테스트 코드 작성 테스트를 실행하고 구현한 코드가 실패하는지 확인 코드 작성 테스트 성공 확인 리팩토링을 통해 중복제거 필자는 아래의 과정을 통해 아래와 같은 점을 느낄 수 있다고 말합니다. 각각의 테스트가 기능의 작은 변경에도 얼마나 커버가 되는지 새 테스트를 동작하기 위해 얼마나 많은 하드 코딩을 하는지 테스트를 얼마나 자주 실행하는지 수없이 작은 단계를 거치면서 수많은 리팩토링을 합니다. ..