기록이 힘이다.

마이크로서비스를 만들기 위한 가장 효율적인 프로세스는 실제로 동작하는 제품 중심의 반복/점진적 애자일 개발 프로세스다. 피드백을 통한 지속적인 개선을 추구하는 애자일 프로세스는 가장 효율적인 의사소통 구조와 협업 체계를 가진 다기능 팀을 필요로 하고, 그러한 다기능 팀이 만들어내는 결과물이 '마이트로서비스'다. 2000년대 초반에 일어난 애자일 문화의 확산과 애자일 방법론의 중심 프랙티스(지속적 통합, 데브옵스 등). 그리고 클라우드 인프라, 마이크로서비스 생태계의 발전은 그 흐름을 함께한다고 볼 수 있다. 그동안 대표적인 애자일 방법론으로 스크럼과 XP 등을 많이 활용해왔다. 그러나 스트럼이나 XP를 살펴보면 개발 문화 및 관리 프로세스에 대해서는 자세히 설명하지만 설계하고 개발하는 엔지니어링 공정에 ..

비즈니스 로직은 어디에? - 관심사의 분리 비즈니스 로직이란 보통 시스템의 목적인 비즈니스 영역의 업무 규칙, 흐름, 개념을 표현하는 용어다. 개발자의 역할은 문제 영역의 비즈니스 로직을 분석 및 이해하고 프로그래밍 언어라는 도구로 잘 표현하는 일이다. 여기서 잘 표현한다는 것은 기능이 잘 동작하는 것과 더불어 이해하기 쉽고 변경하기 쉬운 시스템을 만드는 것을 의미한다. 설계 원칙 중 관심사의 분리라는 원칙이 있다. 이것은 시스템의 각 영역이 처리하는 관심사가 분리되어 잘 관리돼야 한다는 의미이고, 이 원칙은 시스템을 이해하고 변경하기 쉽게 만들어 준다. 이 원칙에 따라 각 영역은 고유 관심사에 의해 분리되고 집중돼야 한다. 모듈화 및 계층화도 이 같은 원칙에 기인한다. 특히 비즈니스를 표현하는 비즈니스..

리액티브 선언: 현대 애플리케이션이 갖춰야 할 바람직한 속성들 아키텍처를 정의하는 과정은 시스템 구축을 위한 여러 가지 비기능 요건(성능, 가용성, 보안, 유지보수성, 확장성 등)을 만족하는 다양한 해결 방법을 찾는 과정이다. 다른 말로 표현하면 여러 문제 영역에 대한 해결책을 찾는 과정이다. 사람들은 기기에 포함된 애플리케이션이 요청에 즉각 응답하고 항상 가동되길 기대한다. reactive의 사전적 의미는 '반응을 보이는'이다. 이는 다양한 상황에 따라 빠르고 적절하게 반응하는 시스템을 의미한다. 급변하는 상황에 적응할 수 있는 시스템을 요구하는 것이다. 리액티브 시스템이 신뢰성 있는 응답을 빠르게 제공하고 부분적 장애가 빨리 복구되고 수요 증가에 탄력적으로 대응하기 위해서는 시스템 자체가 변화와 확장..

VPC란? vpc 정의 독립된 가상의 클라우드 네트워크 vpc 종류 기본 vpc와 사용자 vpc로 나누어 질 수 있습니다. 구분 기본 vpc 사용자 vpc 생성 주체 AWS 사용자 AWS 리소스 정해진 리소스 미리 생성 수동으로 생성 리전 별 생성 수 1개 최대 5개(기본값) vpc 특징 확장성, 보안, 사용자 중심, 제약 사항 기본 네트워크 개념 이해 OSI7 layer TCP/IP 4protocol Application Application Presentation Segment Transport Transport Network Internet Data Link Network Interface Physical IP와 서브넷 마스크 IP 개념 IP는 (Internet Protocol)의 약자로 인터넷상의..

여는글 차선 활동이 애자일 개발 프랙티스 중 하나인 테스트 코드 작성과 지속적 통합을 통한 코드 품질 향상이었다. 당시 SI 현장에는 형상관리 체계나 꾸준히 빌드하는 팀 자체가 드물었기 때문에 젠킨스, 소나큐브 기반의 소스코드 품질향상 활동을 전파하기 위해 노력했다. 이 책은 우리 팀의 4~5년간의 시행착오와 좌충우돌 노력의 산물이다. 소프트웨어 공학이라는 학문이 역사가 오래된 다른 인문학이나 과학, 공학 분야와 달리 법칙과 공식, 선언에 의거하지 않고 역사도 짧은 편이라 완벽한 정답이란 없다고 생각한다. 따라서 앞서간 여러 훌륭한 선배들이나 현시대에 탁월한 활약을 보이고 있는 여러 구루들의 경험을 통해 배우고 우리의 경험과 접목해서 이해하고 정리해 나아가야 한다고 본다. 이 책이 마이크로서비스, 클라우..

단일 모델의 단점 식별자를 이용해서 애그리거트를 참조하는 방식을 사용하면 즉시 로딩과 같은 JPA 의 쿼리 관련 최적화 기능을 사용할 수 없다. 애그리거트 간의 연관을 ID가 아니라 직접 참조하는 방식으로 연결해도 고민거리가 생긴다. 이런 고민이 발생하는 이유는 시스템의 상태를 변경할 때와 조회할 때 단일 도메인 모델을 사용하기 때문이다. ORM 기법은 주문 상세 조회 화면처럼 여러 애그리거트에서 데이터를 가져와 출력하는 기능을 구현하기에는 고려할 게 많아서 구현을 복잡하게 만드는 원인이 된다. 구현 복잡도를 낮추기 위해, 상태 변경을 위한 모델과 조회를 위한 모델을 분리할 수 있다. https://www.youtube.com/watch?v=xf0kXMTFJm8 CQRS 상태 변경 범위와 상태 조회 범위..

시스템 간 강결합 문제 주문 도메인에서 환불을 진행하려고 할때 환불 기능을 제공하는 도메인 서비스를 통해 실행하게 된다. 보통 결제 시스템은 외부에 존재하므로 도메인 서비스에서 외부서비스를 호출한다. 이때 여러 문제가 발생할수 있다. 첫번째로 외부 서비스가 정상이 아닐 경우 트랜잭션 처리를 어떻게 해야하는가? 환불기능 실행중 예외 발생시 롤백할지 커밋할지 애매하다. 두번째로 외부 시스템의 응답이 길어질 경우의 성능 문제이다. 환불 처리 기능이 오래걸릴수록 주문 취소 기능 또한 대기 시간이 증가한다. 즉, 외부 서비스 성능에 직접적인 영향을 받는다. 추가적인 문제로 설계상 문제가 나타날 수 있다. 주문을 표현하는 도메인에 결제 도메인의 환불 로직이 뒤섞이게 된다. 지금 까지 언급한 문제가 발생하는 이유는 ..

도메인 모델과 경계 처음 도메인 모델을 만들 때 빠지기 쉬운 함정이 도메인을 완벽하게 표현하는 단일 모델을 만드는 시도를 하는 것이다. 그런데 1장에서 말한 것처럼 한 도메인은 다시 여러 하위 도메인으로 구분되기 때문에 한 개의 모델로 여러 하위 도메인을 모두 표현하려고 시도하면 오히려 모든 하위 도메인에 맞지 않는 모델을 만들게 된다. 논리적으로 같은 존재처럼 보이지만 하위 도메인에 따라 다른 용어를 사용하는 경우도 있다. 하위 도메인마다 사용하는 용어가 다르기 때문에 올바른 도메인 모델을 개발하려면 하위 도메인마다 모델을 만들어야 한다. 모델은 특정한 컨텍스트(문맥) 하에서 완전한 의미를 갖는다. 같은 제품이라도 카탈로그 컨텍스트와 재고 컨텍스트에서 의미가 서로 다른다. 이렇게 구분되는 경계를 갖는 ..