기록이 힘이다.

도서 대출 시스템 1. 요구사항 정의 2. 이벤트 스토밍을 통한 마이크로서비스 도출 3. 외부 아키텍처 정의 4. 내부 아키텍처 정의 5. JHipster를 이용한 아키텍처 구성 1. 요구사항 정의 사용자 관리 및 로그인 사용자를 등록한다. 등록 시 사내 HR(Human Resource) 시스템에 의해 검증된다. 특정 사용자는 사서의 역할을 부여받는다. 사용자는 시스템 사용을 위해 로그인하거나 로그아웃할 수 있다. 도서 관리 사서는 도서분류정보를 등록/수정/삭제한다. 사서는 입고된 도서를 분류하고 등록/수정/삭제한다. 일반적인 도서는 도서공급사에 의해 공급된다. 각 도서는 대출할 수 있는 수량(재고)이 있으며, 대출/반납에 의해 재고가 조정된다. 도서 대출 및 반납 사용자는 도서를 검색한다. 사용자는 베..

모듈화의 근본적 가치는 각 모듈을 기능적으로 응집성 높게 만들고 기능이 다른 타 모듈 간의 의존도를 낮추는 것이다. 마이크로서비스를 도출하는 방법 시스템의 어떤 비즈니스 기능들을 묶어서 독립적인 마이크로서비스로 도출할 것인가를 결정하는 것이 매우 중요하다. 비즈니스 능력에 근거한 도출 마이크로서비스를 식별하는 가장 쉬운 방법은 경험적인 원칙을 적용하는 것이다. 이러한 방식은 전체적인 대략의 비즈니스를 이해할 때는 유용하지만 서비스 간의 관계를 파악하거나 서비스의 구체 기능과 연관된 서비스가 관리할 독립적인 데이터를 식별하기에는 미흡하다. 이를 보완할 대책이 필요하다. DDD의 바운디드 컨텍스트 기반 도출 비즈니스 능력에 따른 서비스 도출 한계를 극복하기 위해 DDD의 전략적 설계를 적용할 수 있다. 비즈..

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

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

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

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