N° 01 — 목록

'Software Architecture' (51)

  1. Software Architecture/Foundations

    Foundations - 06. IaC 철학

    서버 한 대를 설정하는 데 1시간이면, 100대에는 며칠이 걸린다 — IaC 철학2012년 8월 1일, Knight Capital의 주문 거래 시스템이 뉴욕 증권시장에서 폭주하기 시작했다. 45분 만에 회사가 4억 4천만 달러를 잃었고, 그해 말 파산했다. 나중에 밝혀진 원인은 단순했다 — 8개 서버 중 1대에만 이전 배포의 죽은 코드(DEAD code)가 남아 있었다. 7대에는 새 코드가 정상적으로 배포됐지만, 8번째 서버(RSM-4)는 수동 배포 과정에서 누락됐다. 그 서버가 살아 있던 구 코드가 새로운 거래 플래그를 해석하지 못하고, 시장에 무한히 주문을 쏟아낸 것이다. 이 사건은 자동화된 배포가 없는 인프라가 얼마나 위험한지를 보여주는 잔혹한 사례다. 한 대의 서버 설정이 어긋난 게 전 회사를 무..

    · 댓글
  2. Software Architecture/DDD & Patterns

    DDD Patterns - 10. GoF 디자인 패턴

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

    · 댓글
  3. Software Architecture/DDD & Patterns

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

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

    · 댓글
  4. Software Architecture/DDD & Patterns

    DDD Patterns - 08. 이벤트 스토밍

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

    · 댓글
  5. Software Architecture/DDD & Patterns

    DDD Patterns - 07. 컨텍스트 통합

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

    · 댓글
  6. Software Architecture/DDD & Patterns

    DDD Patterns - 06. 헥사고날 실천

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

    · 댓글

티스토리툴바