일년 전쯤 데이터 메시를 읽고, 더 나은 데이터 파이프라인에 대해 고민하다가 샀던 책이다. 이 책은 데이터 웨어하우스를 넘어서 데이터 플랫폼이 필요한 이유와 클라우드를 이용해 데이터 플랫폼을 구축하는 방법에 대해 세세하게 알려준다. 지금와서 다시보니 새롭게 보이거나 더 공감가는 내용이 많아서 꺼내든 김에 한번 정리하려고 한다. 들어가며 모든 비즈니스에는 데이터 분석이 필요하다. 비즈니스를 하는 곳에서는 항상 비즈니스 지표를 측정하며 이 지표를 기반으로 의사결정을 한다. 최근에 기술발달로 새로운 데이터 관리 구조인 클라우드 기반의 데이터 플랫폼이 나왔다. 클라우드 데이터 플랫폼은 "모든 유형의 데이터를, 거의 무제한의 장소에서 비용 효과적인 클라우드 네이티브 방식으로 수집, 통합, 변환, 분석, 관리되는 ..

SOLID란 객체지향 설계의 5가지 원칙의 앞글자를 따서 만든 단어이다.SRP (Single Responsibility Principle) - 단일 책임 원칙OCP (Open/Closed Principle) - 개방/폐쇄 원칙LSP (Liskov Substitution Principle) - 리스코프 치환 원칙ISP (Interface Segregation Principle) - 인터페이스 분리 원칙DIP (Dependency Inversion Principle) - 의존성 역전 원칙SOLID의 목표는 소프트웨어의 유지보수성과 확장성을 높이는 데에 있다. 그렇다면 설계 관점에서 소프트웨어의 유지보수성을 높인다는 것은 무엇일까?영향범위 - 코드 변경으로 인한 영향범위가 작아야 함의존성 - 의존성을 관리해야..

회사에서 동료에게 추천받은 책. DDD 같은 레이어드 아키텍처나 객체지향을 계속 공부하면서도 실제 개발할 때 적용하는 것이 쉽지만은 않았다. 이 책은 '실용주의'라는 제목답게 이론에 치우치기보다 업무에 바로 적용할만한 예시를 알려준다. 마침 내가 겪고 있던 문제와 완전히 동일한 상황들이 예시로 나와서 많은 도움을 받고 있기에 한번 정리해보려고 한다. 다만 여기서는 자바/스프링으로 예시를 들어주기 때문에 적절하게 파이썬으로 변경했다. 객체지향절차지향과 비교절차지향은 순차지향과는 다르다. 순차지향 프로그래밍의 Sequential은 '순차적으로'라는 뜻으로 말 그대로 코드를 위에서 아래로 읽겠다는 의미.절차는 Procedure로 컴퓨터 공학에서는 함수로 통하기 때문에 절차지향 프로그래밍은 사실상 '함수' 지향..

part 1 에서 전략적 설계 측면에 대해 알아보았다. part 2에서는 전술적 설계 측면에서 ‘방법’에 대해 알아본다.05. 간단한 비즈니스 로직 구현비교적 간단한 비즈니스 로직에 적합한 두 가지 패턴을 살펴보자1. 트랜잭션 스크립트 패턴각 기능별로 스크립트나 메서드 작성하고 비즈니스 로직을 순차적으로 처리하는 방법복잡한 계층 구조 없이도 로직을 구현할 수 있어 단순하고 직관적비즈니스 로직이 단순한 지원 하위 도메인에 적합(ex. ETL 작업)잘못된 트랜잭션 구현 예시트랜잭션 동작 구현 실패전체를 아우르는 트랜잭션 없이 여러 업데이트를 하는 경우→ 데이터 변경을 모두 포함하는 트랜잭션으로 묶어 해결분산 트랜잭션분산 시스템에서는 데이터베이스의 데이터를 변경한 다음 메시지 버스에 메시지를 발행해 다른 컴포..

도메인 주도 설계 방법(Domain-Driven Design; DDD)은 크게 전략적 설계와 전술적 설계 두가지로 나눌 수 있다. 전략적 설계 - What? Why? 어떤 소프트웨어를, 왜 만드는지전술적 설계 - How? 소프트웨어 각각의 구성요소가 구현되는 방법먼저 전략적 설계 관점에서 도메인 주도 설계의 패턴과 원칙을 탐색해보자. 1장 비즈니스 도메인 분석하기비즈니스 도메인기업의 주요 활동 영역으로, 일반적으로 회사가 고객에게 제공하는 서비스ex) 아마존 - 소매업 & 클라우드 서비스하위 도메인비즈니스 도메인의 목표를 달성하기 위해 세분화된 영역으로 하위 도메인끼리 상호작용을 해야 함핵심 하위도메인경쟁업체와 차별화된 서비스로 새로운 제품이나 기존 프로세스를 최적화하여 비용을 줄이는 것회사의 수익성이 ..

올해 1월부터 사내에서 FE/BE/DATA 주니어들을 모아 object 책으로 스터디를 진행했다. object는 객체지향 설계를 다루고 있는 책으로 개발 추천 도서에 꼭 등장하는 책이다. 보통 처음 객체지향에 대해 공부하게 되면 추상화, 다형성, 캡슐화, 상속 이렇게 네가지를 그냥 외우곤한다. 나 또한 처음엔 이론적인 부분을 외우기에 급급했기 때문에 깊은 뜻에 대해서는 이해하지 못한채로 지내왔다. 책에서는 객체지향의 세부원칙들이 어떤 경우에 어떤 목적을 이루기 위해서 나오게 되었는지 자세한 예시코드와 함께 깊이있게 설명을 해준다. 이런 예시들을 보면서 단순하게만 알고 있던 부분에 대해  "아 그래서 그런거였구나!" 하고 깨닫는 순간들이 종종 있었다. 그 중 인상깊었던 부분을 몇가지 소개하자면,SOLID ..

읽기(질의)와 쓰기(명령)는 다르기 때문에 다르게 취급해야 한다 쓰기 위해 존재하는 도메인 모델지금까지 책에서 도메인 규칙을 강화하는 소프트웨어를 만드는 방법을 설명하기 위해 많은 시간과 노력을 들였음제약과 규칙을 정하고 이를 테스트하고, 일관성 보장을 위해 작업단위나 애그리게이트 같은 패턴 도입 이 모든 복잡도는 시스템 상태 변경 즉 데이터를 유연하게 쓰기 위함 > 그렇다면 읽기는? 가구를 구매하지 않는 사용자지금까지의 복잡한 도메인 아키텍처 패턴은 쓰기에서는 도움이 되지만 데이터를 읽는데는 아무 역할도 하지 않음재고 할당보다 제품 뷰 건수가 훨씬 많음 -> 쓰기보다 읽기 작업이 훨씬 많다 쓰기 작업은 일관성이 있게 철저하게 유지해야하지만 읽기는 완벽히 최신일 필요는 없다 (캐시나 읽기 전용 복제본 사..

이번 장에서는 애플리케이션의 내부 구조에서 이벤트를 더 근본적인 요소를 만들면서 시작한다 새로운 아키텍처가 필요한 새로운 요구 사항현실에서는 예기지 못한 상황이 발생할 수 있다 재고 조사를 하는 동안 물이 새서 매트리스 3개가 손상된 것을 발견했다 포크가 배송 지연 되어 몇 주 동안 세관에 머물러야 했다. 그 중 3개가 안전 검사에서 실패해 폐기했다.금속이 부족해져서 다음 책장을 배치를 생산할 수 없게 됐다. 배치 수량이 변경되면 할당을 해제하고 재할당 해야 한다 구조 변경 상상해보기: 모든 것이 이벤트 핸들러서비스 계층 함수에 의해 처리되는 API 호출내부 이벤트와 그 이벤트에 대한 핸들러 모든 것이 이벤트 핸들러라면? > 서비스 계층 함수도 이벤트라고 생각할 수 있다 services.allocate(..

7장으로 1부가 끝나고 2부에서는 시스템이 커졌을 때 이벤트 기반 아키텍처를 통해 애그리게이트와 애플리케이션을 서로 분리하는 방법을 알아볼 예정이다 재고 부족으로 주문 할당이 불가능 한경우 이메일로 이를 통지하는 새로운 (기존과 서비스와 관계 없는) 요구사항 추가된 상황지저분해지지 않게 막기웹 컨트롤러가 지저분해지는 일을 막자 핵심 도메인과 아무 관련없는 요구사항을 아무 생각없이 웹 컨트롤러에 넣기 쉽다하지만 이렇게 이것저것 끼워넣으면 코드가 빠르게 더러워진다 모델이 지저분해지는 일을 막자 도메인 모델은 실제 할당할 수 있는 것보다 더 많은 상품을 할당 할 수 없다는 규칙에만 집중 할 것 도메인 모델의 규칙을 변경하지 않아도 이메일대신 SMS로도 통지를 보낼 수 있어야 함 서비스 계층이 지저분해지는 일을..