오늘은 계층형 아키텍처의 문제점에 대해 알아보겠다. 계층형 아키텍처는 코드에 나쁜 습관들이 스며들기 쉽고.. 시간이 지날수록 소프트웨어를 점점 더 변경하기 어렵게 만드는 수많은 허점들이 생긴다. 위는 전통적인 웹 애플리케이션의 구조이다. 의존성의 마지막은 영속성 계층이므로 애플리케이션은 데이터베이스에 의존하게 된다. 따라서, 어떤 요구사항을 구현할 때 데이터베이스의 구조를 먼저 생각하고 이를 토대로 도메인 로직을 구현하기 쉽다. 즉, 데이터베이스 주도 설계로 유도 되는 것이다. 하지만, 비즈니스 관점에서는 도메인 로직을 먼저 만들어야한다. 도메인 로직이 맞다는 것을 확인한 후에 이를 기반으로 영속성 계층과 웹 계층을 만들어야한다. 또한, ORM 프레임워크를 계층형 아키텍처와 결합하면 비즈니스 규칙을 영속..
가장 간단하게 구현한 시스템 부터 대규모 트래픽을 감당할 수 있을 정도의 시스템 까지 생각하면서.. 시스템 설계 방법을 나열해보겠다.. (아래 내용은 트랜잭션 격리 수준에 따라 내용이 좀 달라질 수 있다.) (틀린 점이 있을 수 있다.. 있으면 댓글 부탁드립니다.) 기술 스택 : Spring, JPA, MySQL 요구사항타임라인 기능 설계에 대해 고민해보자.. 타임라인 기능이란.. 내가 어떤 게시글을 작성하면.. 나를 팔로우하는 사람들은 내 게시글을 각자의 타임라인 페이지(보통 home 페이지이다.)에서 볼 수 있는... 기능이다. 각 방법에서 쓰기 관점과 조회 관점으로 나눠서 설명하겠다. A 사용자가 B 사용자를 팔로우 하였고, B 사용자가 게시글을 쓰는 상황이라 생각하자. 첫번째 방법가장 간단하게 생..
가장 간단하게 구현한 시스템 부터 대규모 트래픽을 감당할 수 있을 정도의 시스템 까지 생각하면서.. 시스템 설계 방법을 나열해보겠다.. (아래 내용은 트랜잭션 격리 수준에 따라 내용이 좀 달라질 수 있다.) (틀린 점이 있을 수 있다.. 있으면 댓글 부탁드립니다.) 기술 스택 : Spring, JPA, MySQL, Redis 요구사항 게시물의 좋아요 기능 설계에 대해서 고민해보자.. 좋아요 카운터를 증가시키는 트랜잭션은 2개의 쿼리로 진행했다. 1. 현재 좋아요 수 조회 2. 좋아요 수 = 현재 좋아요 수 + 1 -> JPA 에서 Dirty Check 기능으로 업데이트하는 것과 같다. 쿼리 1개로 하면 안되나..? -> 밑에서 따로 다룬다. 시스템 설계 방법 첫번째 방법 가장 생각하기 쉬운 방법이다. 위..
개념이 헷갈려 간단하게 정리해보겠다.. 두 개념 모두 분산 환경에서 메시지 교환 방식을 효과적으로 관리하는데 사용되는 패턴이다. Event-Driven Architecture (EDA) 시스템이 특정 이벤트에 반응하여 동작하는 방식이다. 이벤트는 시스템의 상태가 변경되었음을 나타내고, 해당 이벤트는 다른 구성 요소가 구독하거나 반응할 수 있다. 이벤트의 생성, 감지, 소비를 중심으로 하는 아키텍처인 것이다.. 따라서 비동기성, 느슨한 결합 등의 특징이 있다. Pub/Sub Model Event-Driven Architecture 에 속하는 특정 유형이라 볼 수 있다. Publisher 는 이벤트 또는 메시지를 생성하고.. Subscriber 는 해당 메시지를 수신한다. Publisher 와 Subscri..
Hexagonal Architecture 의 각 컴포넌트 별 책임과 주의 사항에 대해 정리해보겠다.. clean architecture 에서는 Application layer 와 Domain layer 를 합쳐서 Application Core 라고 부른다. Application 은 port 와 Use case, Service 가 존재하는 layer 를 뜻하나.. Domain이 포함된 개념으로 불리기도 함. Application 유스케이스 책임 1. 입력을 받는다. 2. 비즈니스 규칙을 검증한다. (도메인 엔티티와 책임 공유) 3. 모델 상태를 조작한다. 4. 출력을 반환한다. 각 유스케이스 마다 다른 입력/출력 모델을 가져가도록 해보자.. 각 입력 모델은 입력 유효성 검증 책임을 가진다. 주의) 입력 유..
CQRS(Command Query Responsibility Segregation) 패턴 에 대해 알아보자... 단어 자체의 해석은.. 명령 조회 책임 분리(커멘드 쿼리 책임 분리)이다. (명령과 조회의 책임을 분리하자) -> 보통 성능이 중요한 조회용 외부 시스템과 비즈니스 명령이 많은 내부 시스템으로 분리한다. 자세한 정의 CQRS 패턴은 도메인에서 발생하는 이벤트와 상태를 분리하여 처리한다. 즉, 명령(Command)과 조회(Query)를 각각 다른 모델로 처리하는 것이다. 명령 모델은 상태 변경을 처리하고, 조회 모델은 상태를 조회한다. 이렇게 하면 각각의 모델은 명확한 역할을 가지게 되어 유지보수 및 확장이 용이해지며, 코드의 복잡성이 줄어들게 된다. 또한 CQRS 패턴은 이벤트 소싱(Event..
대규모 시스템 설계 2023. 6. 22. 23:13
오늘은 계층형 아키텍처의 문제점에 대해 알아보겠다. 계층형 아키텍처는 코드에 나쁜 습관들이 스며들기 쉽고.. 시간이 지날수록 소프트웨어를 점점 더 변경하기 어렵게 만드는 수많은 허점들이 생긴다. 위는 전통적인 웹 애플리케이션의 구조이다. 의존성의 마지막은 영속성 계층이므로 애플리케이션은 데이터베이스에 의존하게 된다. 따라서, 어떤 요구사항을 구현할 때 데이터베이스의 구조를 먼저 생각하고 이를 토대로 도메인 로직을 구현하기 쉽다. 즉, 데이터베이스 주도 설계로 유도 되는 것이다. 하지만, 비즈니스 관점에서는 도메인 로직을 먼저 만들어야한다. 도메인 로직이 맞다는 것을 확인한 후에 이를 기반으로 영속성 계층과 웹 계층을 만들어야한다. 또한, ORM 프레임워크를 계층형 아키텍처와 결합하면 비즈니스 규칙을 영속..
대규모 시스템 설계 2023. 6. 9. 01:59
가장 간단하게 구현한 시스템 부터 대규모 트래픽을 감당할 수 있을 정도의 시스템 까지 생각하면서.. 시스템 설계 방법을 나열해보겠다.. (아래 내용은 트랜잭션 격리 수준에 따라 내용이 좀 달라질 수 있다.) (틀린 점이 있을 수 있다.. 있으면 댓글 부탁드립니다.) 기술 스택 : Spring, JPA, MySQL 요구사항타임라인 기능 설계에 대해 고민해보자.. 타임라인 기능이란.. 내가 어떤 게시글을 작성하면.. 나를 팔로우하는 사람들은 내 게시글을 각자의 타임라인 페이지(보통 home 페이지이다.)에서 볼 수 있는... 기능이다. 각 방법에서 쓰기 관점과 조회 관점으로 나눠서 설명하겠다. A 사용자가 B 사용자를 팔로우 하였고, B 사용자가 게시글을 쓰는 상황이라 생각하자. 첫번째 방법가장 간단하게 생..
대규모 시스템 설계 2023. 6. 8. 22:45
가장 간단하게 구현한 시스템 부터 대규모 트래픽을 감당할 수 있을 정도의 시스템 까지 생각하면서.. 시스템 설계 방법을 나열해보겠다.. (아래 내용은 트랜잭션 격리 수준에 따라 내용이 좀 달라질 수 있다.) (틀린 점이 있을 수 있다.. 있으면 댓글 부탁드립니다.) 기술 스택 : Spring, JPA, MySQL, Redis 요구사항 게시물의 좋아요 기능 설계에 대해서 고민해보자.. 좋아요 카운터를 증가시키는 트랜잭션은 2개의 쿼리로 진행했다. 1. 현재 좋아요 수 조회 2. 좋아요 수 = 현재 좋아요 수 + 1 -> JPA 에서 Dirty Check 기능으로 업데이트하는 것과 같다. 쿼리 1개로 하면 안되나..? -> 밑에서 따로 다룬다. 시스템 설계 방법 첫번째 방법 가장 생각하기 쉬운 방법이다. 위..
대규모 시스템 설계 2023. 6. 3. 02:17
개념이 헷갈려 간단하게 정리해보겠다.. 두 개념 모두 분산 환경에서 메시지 교환 방식을 효과적으로 관리하는데 사용되는 패턴이다. Event-Driven Architecture (EDA) 시스템이 특정 이벤트에 반응하여 동작하는 방식이다. 이벤트는 시스템의 상태가 변경되었음을 나타내고, 해당 이벤트는 다른 구성 요소가 구독하거나 반응할 수 있다. 이벤트의 생성, 감지, 소비를 중심으로 하는 아키텍처인 것이다.. 따라서 비동기성, 느슨한 결합 등의 특징이 있다. Pub/Sub Model Event-Driven Architecture 에 속하는 특정 유형이라 볼 수 있다. Publisher 는 이벤트 또는 메시지를 생성하고.. Subscriber 는 해당 메시지를 수신한다. Publisher 와 Subscri..
대규모 시스템 설계 2023. 5. 15. 20:19
Hexagonal Architecture 의 각 컴포넌트 별 책임과 주의 사항에 대해 정리해보겠다.. clean architecture 에서는 Application layer 와 Domain layer 를 합쳐서 Application Core 라고 부른다. Application 은 port 와 Use case, Service 가 존재하는 layer 를 뜻하나.. Domain이 포함된 개념으로 불리기도 함. Application 유스케이스 책임 1. 입력을 받는다. 2. 비즈니스 규칙을 검증한다. (도메인 엔티티와 책임 공유) 3. 모델 상태를 조작한다. 4. 출력을 반환한다. 각 유스케이스 마다 다른 입력/출력 모델을 가져가도록 해보자.. 각 입력 모델은 입력 유효성 검증 책임을 가진다. 주의) 입력 유..
대규모 시스템 설계 2023. 2. 15. 01:37
CQRS(Command Query Responsibility Segregation) 패턴 에 대해 알아보자... 단어 자체의 해석은.. 명령 조회 책임 분리(커멘드 쿼리 책임 분리)이다. (명령과 조회의 책임을 분리하자) -> 보통 성능이 중요한 조회용 외부 시스템과 비즈니스 명령이 많은 내부 시스템으로 분리한다. 자세한 정의 CQRS 패턴은 도메인에서 발생하는 이벤트와 상태를 분리하여 처리한다. 즉, 명령(Command)과 조회(Query)를 각각 다른 모델로 처리하는 것이다. 명령 모델은 상태 변경을 처리하고, 조회 모델은 상태를 조회한다. 이렇게 하면 각각의 모델은 명확한 역할을 가지게 되어 유지보수 및 확장이 용이해지며, 코드의 복잡성이 줄어들게 된다. 또한 CQRS 패턴은 이벤트 소싱(Event..