N° 01 — 목록

'software-architecture' (49)

  1. Software Architecture/DDD & Patterns

    DDD Patterns - 10. GoF 디자인 패턴

    공구함의 도구는 자리가 있다 — GoF 23개 패턴이 빛나는 자리와 어둡게 되는 자리작은 스타트업에 입사한 주니어를 하나 상상한다. GoF 디자인 패턴 책을 막 다 읽은 그는 첫 업무로 '게시글 좋아요' 기능을 맡았다. 그의 손은 LikeService를 만들기 전에 LikeServiceFactory부터 갔다. 인터페이스를 정의하고, 구현을 분리하고, 빌더로 조립하고, 프록시로 감쌌다. 리뷰 시간에 선배가 물었다 — "좋아요 기능 하나에 클래스가 아홉 개인 이유가 뭔가요?" 주니어는 자신 있게 답했다. "확장성이요." 선배는 한참을 보다가 조용히 PR을 닫았다. 6개월 뒤 그 코드는 좋아요 카운터에 버그가 생겼을 때 다섯 개의 파일을 함께 읽어야 하는 원인이 됐다.이 이야기의 교훈은 "패턴이 나쁘다"가 아..

    · 댓글
  2. Software Architecture/DDD & Patterns

    DDD Patterns - 08. 이벤트 스토밍

    벽에 사건을 붙이는 탐정 — 이벤트 스토밍경찰 드라마를 보면 탐정이 벽에 사건을 붙인다. 사진·메모·실을 연결해 사건의 전모를 재구성한다. 시간 순으로 나열하고, 인과관계로 이으면서 빈 부분(아직 모르는 사건)이 드러나면 거기를 파고든다. 코드를 한 줄도 안 쓰고 사건의 구조를 이해한다.이벤트 스토밍(EventStorming)은 도메인을 이 탐정 보드처럼 다루는 워크숍 기법이다. Alberto Brandolini가 고안했고, 도메인 전문가와 개발자가 함께 벽에 포스트잇을 붙이며 비즈니스 흐름을 재구성한다. 코드를 짜기 전에, 혹은 코드를 고치기 전에 "이 비즈니스에서 무슨 일이 일어나는가"를 가시적으로 만드는 도구다.도메인 이벤트로 시작한다이벤트 스토밍의 출발점은 도메인 이벤트다 — "비즈니스에서 의미 ..

    · 댓글
  3. Software Architecture/DDD & Patterns

    DDD Patterns - 07. 컨텍스트 통합

    두 나라가 교역하는 법 — 바운디드 컨텍스트 통합두 나라가 교역한다고 하자. 한 나라의 언어와 법이 다른 나라에 그대로 통하지 않는다. 공식 대사관(공개 API)을 두거나, 비공식 채널(이벤트 발행)로 소통한다. 국경을 넘을 때 세관(번역 계층)이 물건을 검수하고 규격을 맞춘다. 한 나라가 다른 나라의 법을 그대로 따르면(순응자) 주권을 잃고, 두 나라가 법을 공유하면(공유 커널) 갈등이 잦다.바운디드 컨텍스트 간 통합도 같다. 주문 컨텍스트의 모델이 배송 컨텍스트에 그대로 통하지 않는다 — 두 컨텍스트는 서로 다른 언어(보편 언어)와 규칙을 쓴다. 통합은 두 나라의 외교처럼, 경계에서 번역하고 합의된 방식으로 소통하는 일이다.동기 통합 — 대사관을 통한 공식 접촉가장 단순한 통합은 동기 호출이다. 주문..

    · 댓글
  4. Software Architecture/DDD & Patterns

    DDD Patterns - 06. 헥사고날 실천

    나라마다 콘센트가 다르다 — 포트와 어댑터 실천해외여행을 가면 콘센트 모양이 다르다. 한국은 220V 둥근 핀, 미국은 110V 평평한 핀, 유럽은 굵은 둥근 핀. 노트북(기기)은 어느 나라에서든 같은 일을 한다 — 화면을 띄우고 연산한다. 다만 꽂는 곳(콘센트)이 다르다. 그래서 변환 어댑터를 낀다. 기기 자체를 뜯어고치지 않고, 어댑터만 바꾼다.헥사고날 아키텍처(hexagonal architecture)는 이 구조다. 도메인이 기기이고, 포트(port)가 콘센트 규격이고, 어댑터(adapter)가 변환 플러그다. 도메인은 어떤 외부 기술(DB, 웹 프레임워크, 메시지 큐)에 연결되든 자기 일을 한다. 외부가 바뀌면 어댑터만 교체한다. Alistair Cockburn이 2005년에 제안한 구조로, "포..

    · 댓글
  5. Software Architecture/DDD & Patterns

    DDD Patterns - 05. 빈약한 도메인 모델

    겉만 객체인 가구 — 빈약한 도메인 모델가구 전시장에 가면 진짜 가구처럼 보이는 모형이 있다. 형태·색·질감은 같다. 하지만 서랍을 열면 속이 비어 있고, 의자에 앉으면 무너진다. 쓸 수는 없고 볼 수만 있다.빈약한 도메인 모델(anemic domain model)이 이 전시용 가구다. 클래스가 있고, 필드가 있고, getter/setter가 있다. 객체처럼 보인다. 하지만 행동(비즈니스 로직)이 없다 — 서랍이 비어 있다. 비즈니스 규칙은 서비스 계층으로 도망가고, 객체는 데이터를 담는 주머니로 전락한다. Fowler는 이를 "객체지향의 핵심, 즉 데이터와 행동의 결합을 포기한 안티패턴"이라 불렀다.빈약한 모델 vs 풍성한 모델flowchart TB subgraph Anemic["빈약한 도메인 모..

    · 댓글
  6. Software Architecture/DDD & Patterns

    DDD Patterns - 04. 앤터프라이즈 패턴

    도서관 사서에게 책을 빌리는 법 — Repository, Unit of Work, Specification도서관에서 책을 빌린다고 하자. 서가에 직접 들어가 책을 찾지 않는다. 사서에게 "이 책 찾아주세요" 하면 사서가 가져다 준다 — 책이 어디 칸에 있는지, 분류 체계가 어떻게 되어 있는지 빌리는 사람은 모른다. 여러 권을 한 번에 빌리면 사서가 대출 목록에 한꺼번에 기록한다. 찾을 때는 "파란 표지에 2020년 이후 출간된 소설"이라고 조건을 말한다.엔터프라이즈 패턴은 도메인 객체의 영속(persistence)을 이렇게 사서처럼 다룬다. Fowler의 (PoEAA)가 정리한 세 가지 핵심 패턴 — Repository, Unit of Work, Specification — 은 도메인이 데이터 접근 기술..

    · 댓글

티스토리툴바