🏗️ ARCHITECTURE

[가상 면접 사례로 배우는 대규모 시스템 설계 기초] 6장 : 키-값 저장소 설계

키-값 저장소(key-value store)는 비 관계형 데이터베이스이다. 이 저장소에 저장되는 값은 고유 식별자를 키로 가져야한다.키-값 쌍에서 키는 유일해야 하며 키에 매달린 값은 키를 통해서만 접근할 수 있다.아마존 다이나모memcachedRedis CAP 정리분산 시스템을 설계할 때는 CAP 정리(Consistency, Availability, Partition Tolerance theorem)를 이해하고 있어야 한다.CAP 정리는 데이터 일관성(Consistency), 가용성(Availability), 파티션 감내(Partition Tolerance)라는 세 가지 요구사항을 동시에 만족하는 분산 시스템을 설계하는 것은 불가능하다는 정리다.데이터 일관성 : 분산 시스템에 접속하는 모든 클라이언트는..

[가상 면접 사례로 배우는 대규모 시스템 설계 기초] 7장 : 분산 시스템을 위한 유일 ID 생성기 설계

분산 환경에서 데이터베이스 서버 한 대로는 요구사항을 감당할 수 없을 뿐더러, 여러 데이터베이스 서버를 쓰는 경우에는 지연 시간을 낮추기가 힘들것이다.분산 시스템에서 유일성이 보장되는 ID를 만드는 방법은 아래와 같다.다중 마스터 복제(multi-master replication)데이터베이스의 auto_increment 기능을 활용한다.다음 ID의 값을 구할 때 1씩 증가시키는 것이 아니라, 데이터베이스 서버의 수(k)만큼 증가시킨다.단점여러 데이터 센터에 걸쳐 규모를 늘리기 어렵다.ID의 유일성은 보장되겠지만 그 값이 시간 흐름에 맞추어 커지도록 보장할 수는 없다.→ 로드밸런싱 로직에 따라 하나의 데이터베이스 서버에서 ID를 연속해서 생성하면,     이후 다른 서버에서 생성한 ID는 앞서 생성한 ID..

Onion Architecture란?

Onion Architecture 란? Onion Architecture는 제어의 역전 원칙을 기반으로 도메인 및 서비스 계층을 애플리케이션의 중심에 배치하고, 인프라스트럭쳐를 외부에 배치하는 아키텍처입니다. Onion Architecture는 기존의 3 계층 아키텍쳐와 같이 데이터 계층에 의존하지 않고 실제 도메인 모델에 의존합니다. 기존의 3계층 아키텍처는 모든 계층이 Data Access 레이어 위에 존재해 해당 레이어에 변경사항이 발생하면 모든 레이어에 변경이 발생하는 단점이 있습니다. 반면, Onion Architecture에서는 데이터베이스 유형에 따라 달라지지 않는 저수준의 객체 모델만이 존재하며, 데이터베이스의 실제 유형과 데이터 저장 방법은 Infrastructure 계층에서 결정됩니다...

Facade Pattern과 API Composition

지금 진행 중인 프로젝트는 코어 모듈에 도메인별로 기능을 구현하고, 사용자 애플리케이션과 어드민에서 코어 모듈을 import 해 오픈된 인터페이스를 통해 도메인의 기능을 사용하게끔 구성했습니다. 이를 Onion Architecture라고 하는데, Onion Architecture는 다음 포스팅에서 다뤄보겠습니다. 이번 포스팅에서는 어드민을 개발하면서 동료 개발자분과 어드민 백엔드를 어떻게 구성할지 논의하면서 Facade Pattern과 API Composition의 차이가 궁금해져 알아보았습니다. Facade Pattern Facade Pattern은 디자인 패턴 중 하나로 복잡한 서브 시스템 혹은 서비스들을 간략한 인터페이스로 감싸서 클라이언트에 제공해줍니다. Facade Pattern에서 클라이언트는..

[도메인 주도 설계] 2부 : 모델 주도 설계의 기본 요소

04장 도메인의 격리 계층형 아키텍처 (Layered Architecture) 보조적인 성격의 코드를 비즈니스 객체 안에 직접 작성할 경우 도메인에 관련된 코드가 상당한 양의 도메인과 관련이 없는 다른 코드를 통해 널리 확산될 경우 도메인에 관련된 코드를 확인하고 추론하기가 굉장히 힘들어진다. 그리고 응집력 있고, 모델 주도적인 객체를 구현하는 것이 비현실적인 이야기가 돼버리고 자동화 테스트가 어려워진다. 매우 복잡한 작업을 처리하는 소프트웨어를 만들 경우 관심사의 분리(separation of concern)가 필요하다. 계층화의 핵심 원칙 한 계층의 모든 요소는 오직 같은 계층에 존재하는 다른 요소나 계층상 아래에 위치한 요소에만 의존 위로 거슬러 올라가는 통신은 반드시 간접적인 메커니즘을 거쳐야 함..

[도메인 주도 설계] 1부 : 동작하는 도메인 모델 만들기

도메인 모델링은 가능한 한 사실적인 모델을 만드는 문제가 아니다. 도메인 모델링은 어떤 목적에 따라 제약에 구애받지 않고 현실을 표현하는 영화 제작에 더 가깝다. 영화 제작자가 자신의 경험 가운데 몇 가지 측면을 골라 특유의 방식으로 이야기하고 논지를 펼쳐 나가듯이 도메인 모델러 또한 모델의 유용성에 따라 특정 모델을 선택한다. 도메인 주도 설계에서의 모델의 유용성 모델과 핵심 설계는 서로 영향을 주며 구체화된다. 모델과 구현 간의 긴밀한 연결은 모델을 의미 있게 만들고, 모델의 분석이 최종 산출물인 동작하는 프로그램에 적용되게끔 보장합니다. 모델은 모든 팀 구성원이 사용하는 언어의 중추이다. 모델과 구현이 서로 연결되어 있으므로 개발자와 도메인 전문가가 의사소통하는 데 별도의 번역 절차가 필요하지 않습..