일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- 1차원 DP
- 2차원 dp
- 99클럽
- @BeforeAll
- @BeforeEach
- @Builder
- @Entity
- @GeneratedValue
- @GenericGenerator
- @NoargsConstructor
- @Query
- @Table
- @Transactional
- Actions
- Amazon EFS
- amazon fsx
- Android Studio
- ANSI SQL
- api gateway 설계
- api gateway 필터
- ApplicationEvent
- assertThat
- async/await
- AVG
- AWS
- aws eks
- AWS 프리티어
- Azure
- bind
- bitnami kafka
- Today
- Total
목록전체 글 (251)
기록
시작하면서Git을 사용하다 보면 이런 상황이 자주 생긴다."원격에는 develop 브랜치가 있는데, 로컬에는 없다. 그래서 로컬 브랜치를 만들고 원격 브랜치랑 연결하고 싶다." 이번 글에서는 이럴 때 사용할 수 있는 명령어를 정리해두자.원격 저장소에는 origin/develop 브랜치가 이미 존재함.하지만 로컬에는 develop 브랜치가 없음.로컬에서 develop 브랜치를 생성하고, 원격 브랜치와 연결(tracking) 해야 함.방법 1. checkout으로 로컬 브랜치 만들면서 연결하기git checkout -b develop origin/develop설명:-b develop: 로컬에 develop 브랜치를 새로 만든다.origin/develop: 원격 브랜치를 기준으로 브랜치를 만든다.이 명령어는 ..

설계 목표이 프로젝트에서 내가 세운 데이터 설계의 핵심 목표는 다음과 같았다.비즈니스 흐름을 자연스럽게 표현할 수 있어야 한다예매가 어떤 흐름으로 일어나는지, 각 데이터가 어떻게 연결되는지를 모델링 안에서 바로 드러나게 하고 싶었다.단순하지만 확장 가능한 구조를 만들자처음에는 단순하게 시작하되, "할인 정책 추가", "좌석 상태 관리", "복수 사용자 인증" 같은 변화에도 잘 견딜 수 있도록 설계하고자 했다.테이블 간의 책임을 명확하게 나누자하나의 테이블이 너무 많은 역할을 하지 않도록, 도메인 별로 기능을 쪼개고 의존성을 줄이려 했다.테이블 설계 흐름처음에는 그냥 머릿속에서 "사용자가 로그인하고, 영화를 보고, 예매를 한다"는 시나리오를 자연어로 풀어보는 데서 시작했다.그 다음으로 각 개체(Entity..
보호되어 있는 글입니다.
보호되어 있는 글입니다.
이전 포스팅에서는 도메인별로 나눠진 멀티 모듈 구조(service-membership, service-movie 등)를 소개했었다.하지만 실제 실습을 진행하면서 몇 가지 한계를 느꼈다.Redis 캐싱 최적화와 같은 기능 중심 개발을 하기에 도메인별 분리는 오히려 복잡했다.도메인 간 기능이 얽힐 때, 레이어 경계를 넘는 작업이 불필요하게 많아졌다.유지보수성과 테스트 효율성을 위해 더 명확한 계층 분리가 필요했다.그래서 이번엔 도메인 중심이 아닌 Layer 중심의 구조로 재설계했다. 이 글은 그 구조와 설계 의도를 간단히 정리한 글이다.🧱 새로운 프로젝트 구조platform (루트 프로젝트)├── bootstrap # 애플리케이션 실행 모듈 (모든 모듈 통합 실행)├── ..
프리티어는 t2.micro 인스턴스 한 대를 무료로 제공해 주기 때문에, 간단한 서비스나 테스트 용도로 사용하기에 꽤 유용하다. 하지만 단점도 있다. 계정마다 리소스 한도가 제한되어 있기 때문에, 여러 개의 계정을 운영하거나 계정 간에 인프라를 동일하게 구성해야 할 일이 자주 생긴다.이럴 때 매번 콘솔을 통해 수동으로 VPC를 만들고, 서브넷과 라우팅 테이블, EC2 인스턴스를 구성하는 일은 번거롭고 시간이 많이 든다.그래서 이를 코드화해두면 여러 계정에서도 복사-붙여넣기만으로 동일한 인프라를 쉽게 구축할 수 있다. 이번 글에서는 AWS CloudFormation 템플릿을 통해 프리티어 기반의 ECS(EC2 LaunchType) 인프라를 구성하는 과정을 소개한다.1. 네트워크 구성 - VPC, 퍼블릭 서..
이번 포스팅에서는 영화 정보를 관리하는 service-movie 모듈을 헥사고날 아키텍처(Hexagonal Architecture) 기반으로 설계하고 구현한 과정을 자세히 소개한다. 이번에는 도메인 중심으로 책임을 분리하는 헥사고날 아키텍처의 힘을 실제 프로젝트에 적용해봤다.🎯 왜 헥사고날 아키텍처를 적용했는가?일반적인 계층형 구조에서는 Controller, Service, Repository로 기능을 나누지만, 시간이 지나면서 Service에 모든 책임이 몰리고, 비즈니스 규칙과 기술 코드가 뒤섞이기 쉬웠다.헥사고날 아키텍처는 다음과 같은 명확한 목표를 가지고 있다:핵심 도메인 로직 보호: 비즈니스 핵심 규칙은 외부 기술(JPA, Redis 등)에 의존하지 않아야 한다.기술 독립성 확보: 외부 시스템..
최근에 영화 예매 시스템을 멀티 모듈 구조로 구성해봤다. DDD + 헥사고날 아키텍처를 바탕으로 각 기능을 명확히 분리하고, 유지보수성과 확장성을 고려한 구조다. 이 글에서는 프로젝트 구조, 각 모듈의 역할, 그리고 설계 의도를 정리해본다.📦 프로젝트 구조platform├── bootstrap # 모든 모듈을 실행하는 엔트리 포인트├── common # 공통 모듈 (DTO, 설정, 예외, 유틸 등)├── service-membership # 회원 관리 서비스├── service-movie # 영화 정보 및 상영 일정 관리└── service-reservation # 좌석 예약 및 예약 상태 관리platfo..