N° 01 — 목록

'Software Architecture' (49)

  1. Software Architecture/DDD & Patterns

    DDD Patterns - 09. 리팩터링과 진화

    정원은 한 번에 만드는 게 아니다 — 리팩터링과 진화정원을 가꾼다고 하자. 씨앗을 심고, 싹이 트면 가지를 치고, 자라면 옮겨 심는다. 한 번에 완성된 정원을 만들 수 없다 — 식물이 자라는 속도가 있고, 계절이 바뀌고, 무엇이 잘 자랄지 실제로 길러봐야 안다. 처음부터 완벽한 설계도를 그려놓고 파종하는 정원사는 없다.소프트웨어도 같다. 처음에 완벽한 도메인 모델을 설계하고 구현하는 건 현실적이지 않다. 도메인에 대한 이해가 코드를 짜면서, 운영하면서, 요구사항이 바뀌면서 깊어진다. 그래서 모델은 진화한다 — 애그리거트 경계가 조정되고, 새 값 객체가 생기고, 서비스가 도메인으로 흡수된다. 이 진화를 안전하게 이끄는 것이 리팩터링이다.리팩터링 — 행동을 보존하며 구조를 바꾼다Fowler는 에서 리팩터링을..

    · 댓글
  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 — 은 도메인이 데이터 접근 기술..

    · 댓글

티스토리툴바