DDD

소프트웨어에서 말하는 불변성 Immutability 이라는 것이 있다. 즉 변하지 않는다는 것 이다. 다른 말로는 읽기 전용이라고도 해석할 수 있다. 무엇이 변하지 않는다는 것일까? 객체 지향 프로그래밍으로 좁혀서 생각해 보면 한번 만들어진 객체가 변하지 않다는 것을 의미 한다. 불변 클래스란 간단히 말해 그 인스턴스의 내부 값을 수정할 수 없는 클래스다.(중략)불변 클래스는 가변 클래스보다 설계하고 구현하고 사용하기 쉬우며, 오류가 생길 여지도 적고 훨씬 안전하다. - 이펙티브 자바 3판, 105 쪽...

지금까지 고객이 구매할 수 있는 오퍼 Offering 를 만들고 [1] 쇼핑몰에 노출하였다. [2] 그다음으로 해야 할 일은 오퍼를 장바구니에 담는 것이다. ShoppingCartService는 마이크로서비스 모듈로서 장바구니를 책임진다. Mall은 ShoppingCartService의 API를 이용하여 오퍼를 장바구니에 담는다. 불변성과 의존성 장바구니는 여러 개의 장바구니 아이템을 담을 수 있다. 여기서 오퍼라 하지 않고 ‘장바구니 아이템’이라고 부른 이유는 장바구니에는 오퍼뿐만 아니라 다른 것도 담을 수 있다는 추상적인 의미가 담겨 있다....

지난 이야기 지난 글 에서는 상품을 유연하게 다루기 위한 시도로 오퍼 Offering 개념을 구현하였다. 개발 주기 목표 오퍼는 존재만으로는 가치가 없다. 고객이 보고 구매함으로써 비로소 가치가 생긴다. 그래서 이번 개발 주기의 목표는 고객이 방문할 수 있는 쇼핑몰(이하 Mall)을 만들고 오퍼를 노출하는 것으로 정했다. Mall은 별도로 존재하는 웹 애플리케이션으로 고객이 상품을 보고 장바구니에 담고 구매할 수 있는 온라인 쇼핑몰이다. Mall 웹 애플리케이션...

지난 이야기 지난 글 에서는 개발 일지를 쓰게 된 배경을 설명했고 간단하게 상품 마이크로서비스를 구현해 보았다. 상품을 보다 유연하게 다루기 몇 년 전 함께 일했던 기획자가 상품(Product)을 분리하자는 제안을 했다. 상품에는 잘 변하지 않는 요소(바코드, 제조사, 원가 등)와 자주 변하는 요소(판매 조건 등)가 있는데 상품 하나로 다루다 보니 유연성이 떨어진다는 것이었다. 유연성이 떨어진다는 말은 무엇을 의미하는 것일까? ' 커머스 혹은 유통 도메인 설계에 대한 연작...

필자가 가지고 있는 자산 중 하나는 전자상거래(이하 커머스) 도메인에서의 개발 경험이다. 오픈소스가 세상을 바꾸어가는 모습을 지켜보면서 개인의 보이지 않는 경험이라는 무형의 자산 으로 머무는 것이 아나라 구체화하여 코드라는 유형의 자산 으로 만들고 싶은 욕구가 있었다. 밈 Meme ‘페르시아 왕자’라는 책 이 있다. 동명 게임의 개발 일지인데 어린 시절 이 게임에 푹 빠져 밤을 지새우며 했던 기억이 아직도 생생하다. 갑자기 웬 게임일까? [caption id="attachment_25949" align="alignnone" width="409"]...

아침에 출근했더니 동료 가 나에게 링크 를 하나 던지며 이렇게 말했다. 위 블로그가 어제 말한 오퍼레이션 캐쉬 설명하는것 같은데 한번 검토해주실수있을까요? Why duplication isn’t always a bad thing in micro-services CTO님이 데이터 중복이 필요할 때가 있다고 설파하던 기억이 난다. 그 당시 대부분의 개발자들이 못알아듣는 눈치였는데, 역시 사람들이 배워서 써먹는 데에는 자기만의 시간이 있다. 귀로 듣거나 책으로만 읽어서는 알 수 없고, 자기 삶에서 그 장면을 만나야 한다. 반갑게도...

비동기 메시지를 사용하여 상호 간에 통신하는 방식을 메시징 Messaging[1] 이라고 부른다. 마이크로서비스 환경에서 비동기 처리 시 보통 카프카 Kafka 나 래빗엠큐 RabbitMQ 같은 메시지 브로커 Message Broker 를 사용하여 메시징을 구현한다. 아래와 같이 마이크로서비스들이 메시징을 통해 협업하여 주문을 처리한다고 가정해보자. OrderService는 주문 상태 이벤트(예. ORDER_CREATED, ORDER_CANCELLED 등)를 메시지 브로커에 발행하고 이벤트에 관심 있는 서비스가 구독하여 처리한다. 주문 상태 이벤트의 발행은 두 가지로 구분할 수 있다....

즉흥적인 글을 하나 쓰다 말고 방치해뒀는데, 이제라도 보완해서 발행한다. 꽤 시간이 지난 글 에 대해 독자 한분께서 댓글을 주셨는데, 주제 특성상 하염없이 미룰 가능성이 높아 즉흥적인 생각을 풀어놓는다. 그래서, 이번 글을 김성현 님 특집이라고 해도 좋을 듯 하다. [caption id="attachment_21193" align="aligncenter" width="600"] 지난 글에 대한 popit 독자님의 질문[/caption] 마침 오전에 있던 서비스에 대한 짧은 대화 출근하자마자 위챗으로 한 지인 께서 URL 하나...

해당 코드는 Github 를 확인해주세요. Spring Guide Test 전략 가이드 Exception 전략 가이드 Domain 객체 가이드 외부 API 가이드 Service 적절한 크기 가이드 도메인 객체는 우리가 해결하고자 하는 핵심 비즈니스 로직이 반영되는 곳입니다. 특히 도메인 객체에서 자기 자신의 책임을 충분히 다하지 않으면 그 로직들은 자연스럽게 Service 영역 및 외부 영역에서 해당 책임 넘겨받아 구현하게 됩니다. 본인의 책임을 다하는 도메인 객체를 만들고 다른 레이어와 어떻게 메시지를 주고받는지 포스팅을 진행하겠습니다....

그런 일이 가능할까? DDD 같은 개념서를 다 읽지도 않고, 필요한 내용만 대충 훑어서 써먹는 식 말이다. 못할 이유가 뭐가 있는가? 가능하다. 책을 다 읽는다고 해도 소화한 내용 중에서 당장 응용할만한 부분만 구현에 써먹기 마련이다. 책을 다 읽으나 안 읽으나 어차피 일부만 소화해서 써먹을 수 있다면, 책을 안 읽고 써먹는 방법이 있다면 시도해보지 않을 이유가 없지 않는가? 물론, 그렇다고 책을 읽지 말자고 선동하는 것은 아니고 목적은 내 실력 배양에 있고, 응용을 해야 실력이 는다는 점을 강조하는 것이다....