Topic
도메인 모델링
비즈니스 개념과 소유권, 이벤트, 경계를 코드에 드러내는 방법을 다룹니다.
임시 저장의 의미로 상태와 별도 저장소 선택하기
일반적인 생명주기 단계는 상태로, 별도 의미를 가진 준비 데이터는 버전 저장소로 다루되 도메인 의미와 호환 비용을 기준으로 선택합니다.
조직 현실까지 고려한 데이터 관계 설계
단순한 관계에서 시작하되 실제 요구사항 변경, 의사결정 습관과 일정 제약을 관찰해 데이터 관계 설계에 반영합니다.
모든 도메인을 삼키는 어드민 공통 모듈을 피하라
어드민 요구가 도메인 의존성을 뒤집지 않게 서비스 경계를 지키고, 요구가 계속 갈라지는 동안 작은 중복을 허용합니다.
정보와 행동을 함께 보는 도메인 개념 도출법
정보와 프로세스 또는 행동을 사례별 관점에서 살펴 전송 이벤트와 도메인 개념을 구분하는 방법입니다.
도메인 개념과 데이터베이스 테이블이 일대일이 아닌 이유
모든 테이블을 도메인 객체와 리포지토리로 복제하지 않고 비즈니스 중요도, 위계와 행동을 기준으로 모델링하는 법을 설명합니다.
도메인 지식을 실무 문제 해결로 증명하는 법
운영, 정책과 부서 간 문제에서 도메인 지식을 쌓고 용어가 아니라 실제 판단과 해결 과정으로 역량을 증명하는 방법을 다룹니다.
개념의 생명주기로 도메인 경계를 찾는 법
생성, 조회, 수정, 삭제 주기를 비교해 상품, 주문, 결제, 배송, 정산의 응집과 경계를 판단합니다.
주문 스냅샷을 지키는 소프트 삭제와 도메인 경계
현재 상품과 주문 스냅샷의 경계를 나누고, 환불 이력을 보존하며 파괴적 삭제 전에 상태 전환과 보관을 검토합니다.
핵심 엔티티를 가볍게 지키는 연관관계 설계
생명주기와 책임으로 ORM 연관관계를 판단하고, 검색용 부가 데이터를 분리해 핵심 엔티티를 단순하게 유지합니다.
열거형인가 코드 테이블인가: 변화 주기로 결정하라
안정적인 값은 열거형으로, 자주 바뀌는 데이터는 전용 테이블로 관리해 공통 코드 테이블이 잡동사니 저장소가 되는 일을 막는다.
하나의 DB에서도 도메인별 데이터 접근 경계를 나누는 법
같은 DB 테이블을 쓰더라도 엔티티와 저장소 경계를 나눠 외부 연동 코드로부터 핵심 규칙을 보호하는 방법을 설명한다.
관리비 고지서에서 연체 도메인을 발견한 순간
평범한 고지서에서 상환 모델의 빠진 개념을 발견하고, 현실의 단서를 검증 가능한 소프트웨어 경계로 바꾸는 과정을 살펴본다.
설계 자원을 쓰기 전에 핵심 개념의 우선순위를 정하라
1급 도메인 개념을 찾고 보조 흐름을 분리해, 제한된 설계 시간을 변화의 중심에 쓰는 실용적인 방법을 설명한다.
순환 참조를 고치기 전에 도메인 경계부터 바로잡기
인터페이스나 의존성 역전으로 순환 참조처럼 보이는 문제를 다루기 전에 모호한 소유권과 개념 경계를 먼저 정리한다.
운영 이슈를 팀의 공통 도메인 지식으로 바꾸는 법
운영 이슈 리뷰, 작업 기록, 개념도, 운영 교대를 활용해 소프트웨어 팀의 도메인 지식 격차를 줄이는 방법을 다룬다.
아웃박스 폴링을 바꾸기 전에 측정하라
현실적인 부하로 아웃박스 폴링을 검증하고, 로그 테일링을 도입하기 전에 더 단순한 애플리케이션 전달 방식을 검토한다.
비즈니스 흐름이 보이는 곳에서 이벤트 발행하기
완료된 비즈니스 행위를 이해하는 계층에서 이벤트를 발행하되, 구현과 밀접한 예외는 명시적으로 구분하는 방법을 다룬다.
'마이'는 왜 도메인이 아닌가
마이페이지는 클라이언트가 보는 화면이지 비즈니스 도메인이 아닙니다. 주문, 상품, 쿠폰은 원래 주인에게 두고 경계에서 조합합니다.
도메인 간 행위는 책임의 주인에게 맡겨라
호출자 쪽 인터페이스를 모듈 사이에 두기 전에 행위의 주인을 정하고, 호출자가 그 도메인의 기능을 의존하게 만드는 기준을 설명합니다.
여러 도메인을 엮는 코드는 어디에 둘까
주된 행위와 다른 도메인의 규칙을 함께 다루는 코드를 비즈니스 소유권, 응집, 임포트, 패키지 이동 실험으로 배치하는 방법입니다.
도메인 모델을 먼저 보는 보수적인 JPA 연관관계 설계
ID에서 시작하고 생명주기가 실제로 맞을 때만 연관관계를 추가하며, 비즈니스 개념은 엔티티와 독립적으로 표현하는 방법을 다룹니다.
도메인이 성숙하기 전에 모듈부터 나누지 마세요
도메인 성숙도는 정책과 행동, 운영 현실을 얼마나 이해했는지에서 나옵니다. 추측을 일찍 굳히지 말고 운영에서 드러난 책임으로 모듈 경계를 정해야 합니다.