N° 01 — 목록
'Software Architecture' (50)
-
Software Architecture/Architectural StylesArchitectural Styles - 04. 클린 아키텍처
클린 아키텍처 — 의존성 규칙을 동심원으로 그리기2012년, Robert C. Martin은 자신의 블로그에 'Clean Architecture'라는 글을 올렸다. 거기 그린 그림은 동심원이었다 — 가운데 Entities, 그 바깥으로 Use Cases, Interface Adapters, Frameworks & Drivers가 겹겹이 둘러싼 모양. 이 그림은 5년 뒤 같은 이름의 책(, 2017)이 되고, 동시대에 Jeffrey Palermo가 제안한 'Onion Architecture'(2008)와 거의 같은 구조로 통합됐다. 동심원 그림은 인터넷에 널리 퍼졌지만, 정작 핵심은 그림이 아니다. 동심원은 발상을 시각화한 부수물이고, 본질은 '의존성 규칙(dependency rule)'이라는 한 문장에 ..
-
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..