N° 01 — 목록
'software-architecture' (49)
-
Software Architecture/Architectural StylesArchitectural Styles - 03. 헥사고날 아키텍처
헥사고날 아키텍처 — 도메인을 프레임워크로부터 격리하기2005년, Alistair Cockburn은 자신의 웹사이트에 "Ports and Adapters"라는 패턴을 올렸다. 그가 풀고자 했던 문제는 단순했다 — "같은 비즈니스 로직이 GUI, CLI, 테스트, 다른 애플리케이션에서 다시 작성되는 일"을 피하는 것. 그가 그린 그림은 도메인을 중심에 두고 여섯 개의 변이 둘러싼 육각형이었다. 이름은 헥사고날(hexagonal)이 됐고, 그 육각형의 변이 '포트(port)'가 됐다. 20년이 지난 지금, 이 패턴은 DDD 진영에서 가장 널리 쓰이는 구조적 패턴이 됐다. 그런데 이름은 자주 쓰이면서 본질은 자주 오해받는다. 헥사고날의 핵심은 '육각형 모양'이 아니라 '의존성 방향'이다.비유로 감 잡기 — 가..
-
Software Architecture/Architectural StylesArchitectural Styles - 02. 계층형 아키텍처
계층형 아키텍처 — 가장 흔한 구조가 품은 함정Spring Boot 프로젝트를 하나 열어보자. controller, service, repository 패키지가 보인다. 어쩌면 자바 웹 애플리케이션의 90%가 이 구조로 돼 있다. 이름은 계층형 아키텍처(layered architecture). 너무 흔해서 '스타일'로 의식하지 못할 정도다. 하지만 이 흔함이 숨기는 함정이 있다 — 계층을 나눴다고 해서 결합이 낮아지는 건 아니다. 계층 사이의 규칙이 결합을 낮춘다.비유로 감 잡기 — 식당의 층별 배치3층짜리 식당을 상상하자. 1층은 홀(손님 응대, 메뉴 설명). 2층은 주방(요리). 3층은 창고(재료 보관). 손님이 1층에서 주문하면 주문서가 2층으로 올라가고, 2층 주방이 3층 창고에서 재료를 꺼내 요..
-
Software Architecture/Architectural StylesArchitectural Styles - 01. 모놀리스
모놀리스가 다시 출발점이 된 이유2015년 무렵 한 스타트업이 하루 처리 건수 10만을 넘기며 모놀리스를 마이크로서비스로 쪼갰다. "모놀리스는 스케일이 안 된다"는 조언을 따른 선택이었다. 6개월 뒤 그 팀이 직면한 것은 트래픽 처리의 성공이 아니라 배포 파이프라인 8배, 분산 트랜잭션 버그, 그리고 "어느 서비스에서 로그가 끊겼는지"를 찾느라 보내는 새벽이었다. 모놀리스 시절 한 번에 끝나던 배포가 여덟 개 서비스의 버전 정합성을 맞추는 일로 바뀌었다. 그들이 진짜 필요했던 건 "모놀리스를 버리는 것"이 아니라 "모놀리스 안의 모듈 경계를 명확히 하는 것"이었다.흥미로운 건 마이크로서비스를 대중화한 책 의 저자 Sam Newman이 2판(2021)에서 오히려 "모놀리스 먼저(monolith first)..
-
Software Architecture/PrinciplesPrinciples - 08. 복잡성의 원천
흙은 없앨 수 없지만 잡초는 뽑을 수 있다 — 복잡성의 원천정원을 가꾼다고 하자. 흙이 있다 — 식물이 자라려면 흙이 필요하고, 흙의 종류·배수성·영양분이 복잡하다. 이건 정원의 본질이다, 없앨 수 없다. 하지만 잡초도 있다 — 우리가 심지 않았는데 자라난 것, 영양분을 빼앗고 정원을 어지럽힌다. 이건 뽑을 수 있다. "정원이 복잡하다"고만 말하면 흙과 잡초를 구분 못 한다 — 무엇이 본질이고 무엇이 우리가 만든 것인가를 가려야 한다.소프트웨어 복잡성도 두 종류다. Fred Brooks는 (1986)에서 본질적 복잡성(essential complexity)과 우발적 복잡성(accidental complexity)을 나눴다. 본질적 복잡성은 문제 자체에서 온다 — 결제 도메인의 복잡한 규칙, 동시성 요구,..
-
Software Architecture/PrinciplesPrinciples - 07. 오류 처리 전략
배송 실패와 화물 사고는 다르다 — 오류 처리 전략택배를 보낸다고 하자. 수취인이 부재중이라 배송이 실패했다 — 이건 정상 흐름의 일부다. 내일 다시 배달하면 된다(복구 가능). 하지만 트럭이 사고를 내어 화물이 전소했다 — 이건 정상 흐름이 아니다. 운송 자체가 중단되고, 보상 청구라는 전혀 다른 경로로 넘어간다(복원 불가능).소프트웨어 오류도 이 두 종류로 나뉜다. 복구 가능한 오류(입력 검증 실패, 리소스 부족)는 정상 흐름의 일부로 다뤄야 하고, 복원 불가능한 오류(디스크 고장, 메모리 부족)는 흐름을 중단시키고 상위로 알려야 한다. 이 둘을 구분하지 않고 모두 예외로 던지면, 호출자가 매번 try-catch를 쳐야 하고 정상 흐름이 예외 처리에 묻힌다.예외 vs 결과 값 — 두 접근예외(exce..
-
Software Architecture/PrinciplesPrinciples - 06. 계약 설계와 API
메뉴판은 계약서다 — 계약 설계와 API식당에서 메뉴판을 본다. "된장찌개 8,000원"이라고 적혀 있다. 이 한 줄이 계약이다 — 8,000원을 내면(사전 조건) 된장찌개를 받는다(사후 조건). 주방에서 어떤 냄비를 쓰는지, 몇 분 끓이는지는 모른다. 메뉴판이 약속한 것만 지켜지면 된다. 메뉴판이 바뀌면(가격 인상, 메뉴 삭제) 손님이 혼란스럽다 — 계약이 변경된 것이다.소프트웨어의 API도 같다. 메서드 시그니처가 메뉴판이고, 호출 규칙이 계약이다. Bertrand Meyer는 에서 이를 계약에 의한 설계(Design by Contract)로 정식화했다 — 사전 조건(precondition), 사후 조건(postcondition), 불변 조건(invariant) 세 가지로 계약을 명시한다.사전 조건과..