Go Gradually - Repository

본 글은 AI의 코드 리뷰가 필요하다 라는 관점에서 작성된 글입니다.최근에 AI 코드를 리뷰하지 않고 커밋하는 경우도 많다는 걸 알고 있으며,이러한 개발방식을 선호하시는 분들은 글이 유의미하지 않을 수 있습니다. 본 글은 제가 기본적으로 알고 있는 지식과 적용하던 절차를 바탕으로 작성된 글입니다.이 과정이 만약 비효율적이거나 더 좋은 방법이 있다면, 언제든 수정될 수 있습니다.최신 수정일자: 2026/03/15 요새는 구현 부분을 AI가 많이 대체하고 있다. 과거에는 기존에 TDD/구현을 직접 해보면서 요구사항 분석에 깊이가 깊어지던 시간이 있었다.이 과정은 코드 산출물을 직접 만들면서 요구사항을 이해했기 때문에, 코드 작성 시간 시점에서 효율적이었다. 하지만, 이젠 코드 자체의 작성 시간이 AI로 인해..

이 게시글을 검색해서 탐색했다는 것은, 객체지향 패러다임 중에서도 OOD와, 그 중간에 사용되는 GRASP 패턴의 목적에 대해 찾아보고자 했다고 가정한다.실제로 코드를 짜면서 쉽게 알게되는 부분을 제외하고, OOD(Object Oriented Design) 관점에서의 객체지향에 대해 설명하도록 하겠다.다소 추상적이고 이론적으로 들리지만, 그만큼 의식적이고 체계적으로 적용하게 되면 일관성 있는 코드가 나온다.웹 구현에서 객체지향적인 코드는 어떻게 나오는지에 대한 고찰을 담았다.권장하는 이전 글 - SOLID 원칙목차OOP(Object-Orientied Paradigm)이란?OOP에서 이야기하는 "책임"이 무엇인가?분석 - OOA설계 - OOD설계 - Interaction Diagram적절한 책임의 할당 -..

사전 지식 - GRASP 패턴도메인 주도 설계(Domain-Driven Design) 란?도메인 주도 설계(Domain-Driven Design)는 소프트웨어의 핵심 비즈니스 도메인에 집중하여 복잡한 도메인 지식을 코드의 도메인 모델로 표현하고 발전시키는 설계 철학이다.DDD는 복잡한 비즈니스 로직을 도메인 모델(객체 모델)로 추상화함으로써 비즈니스에서 발생하는 현실과 코드 간의 간극을 줄인다. 이를 위해 도메인 전문가와 개발자는 공유하는 보편 언어(Ubiquitous Language)를 구축하여 요구사항 분석부터 설계, 구현까지 동일한 언어로 소통한다. 이 과정에서 모델은 지속적으로 정제되고 리팩토링되어, 요구사항의 의도를 코드에 정확히 반영하게 된다. DDD는 왜 사용하는가?전통적인 데이터 중심 설..

이벤트는 일반적으로 비동기 작업 시 굉장히 유리함을 갖기 때문에 자주 사용하게 된다.도메인 이벤트와 애플리케이션 이벤트의 차이점에 대해 알아보자.주의) 이벤트의 정의는 발행자가 결정하는 것이고, 아래 설명은 모두 "발행자" 기준으로 된 설명이다.도메인 이벤트도메인 이벤트(Domain Event)란 비즈니스 관점의 이벤트를 의미한다.도메인 모델 내에서 “무엇이 실제로 발생했는지”를 표현하는데 집중하며, 도메인 언어를 사용하여 표현한다.주로 “주문이 생성되었다”, “새로운 손님이 입장했다”와 같은 방식으로, 비즈니스적 상황의 변화를 알리는데 집중한다.목적도메인 모델 간 결합도를 최소화하는데 사용한다.Event Sourcing 구현 시 상태를 복원할 수 있는 근거를 제공하는데 사용한다.비즈니스 규칙 변경에 따..

사전 지식Child Entity란 무엇인가?도메인 모델 완전성과 도메인 모델 순수성JDBC로 Aggregate Root의 Repository를 설계하면서 도메인 모델 순수성을 지키려고 하다 보면, JDBC로는 도메인 모델 생성/수정/삭제 로직으로 영속성 데이터를 변경할 수 없다.우리가 JPA의 Dirty Checking 에 익숙해져있기에 눈치채지 못하지만, 일반적으로 도메인 모델이 수정되었다고 해당 사항이 즉시 반영되진 않는다.JPA는 (양방향+CascadeType.PERSIST+orphanRemoval = true의 경우) 리스트에 추가/삭제하는 것만으로 객체의 생성/삭제 로직을 자동으로 SQL 문으로 만들어 쿼리해준다.하지만, JDBC의 생성/삭제는 Dirty Checking을 통한 자동 쿼리 생성이..

DDD에서 객체는 id, state, operation 이 세가지를 가지고 있어야 Entity로 승격된다.사전 지식 - Entity로 인정받기 위한 3가지 요소ID다른 객체와 구분할 식별자가 필요하다.State객체가 스스로 자신의 상태를 가져야 한다.Operation객체가 스스로 행동하기 위해 정의된 규칙이 있어야 한다.지금부터 위 기초 지식을 바탕으로, Child Entity와 Value Object, DTO 세가지를 분류/분석해보자.Child Entity애그리거트 루트의 하위 엔티티 중, VO가 아닌 것.ID, State, Operation을 모두 가져야 한다.Child Entity의 경우, 외부와 직접 상호작용하는 로직 없이, 자신의 영역 내에서만 관리되는 비즈니스 로직을 가져야 한다.모든 로직이 ..

의인화(Anthropomorphism)란?소프트웨어 객체를 능동적이고 자율적인 존재로 설계하는 원칙.객체를 마치 사람처럼 직접 행동하는 “자아를 가진 존재”로 다루는 것을 의미한다.- Rebecca Wirfs-Brock - 도메인 이벤트, 상태 머신, 이벤트 소싱, CQRS, 그리고 DDD(도메인 주도 설계)는 서로 유기적으로 결합되어 응집도 높은 설계를 만든다. 본 글에서는 강아지 키우기 예제를 통해 이러한 개념들을 이해해보고, 실제 구현 시 고려해야 할 디테일과 도전 과제들을 이야기하도록 하겠다. 먼저 해당 링크를 통해, 도메인 이벤트의 정의에 대해 이해하길 바란다.예제 - 강아지 키우기우리가 설계해야 할 소프트웨어 모델은, 단순 CRUD 를 넘어 좀 더 능동적으로 스스로 행동하는 객체를 만들어야 할..

도메인 서비스란?서로 다른 애그리거트간, 협력을 중재하는 객체이다.보통 싱글톤으로, Pure Fabrication 형태를 띄며 정의된다.도메인 서비스의 개념 자체는 매우 단순하다.우리가 쉽게 만들어 쓰는, 애플리케이션 서비스와 별 차이가 없어 보인다도메인 서비스, 그럼 스프링 빈으로 사용해도 되나?가능하다.스프링의 빈(Bean) 관리 메커니즘을 활용하여 싱글톤 객체로 등록해두면 편리하게 재사용할 수 있다.다만 애플리케이션 레이어(서비스 레이어)와 명확히 구분할 필요가 있다.단순히 스프링 빈으로 등록했다고 해서 인프라 계층 로직을 무조건 포함해야 하는 것은 아니다.그럼 도메인 서비스가 스프링 컨테이너에 의해 생성되는데, 인프라 로직에 종속된거 아닌가?실제 인프라 로직은, 선언한 빈을 통해 바이트 코드로 구..

다음 글은 블라디미르 코리코프의 DDD 트릴레마를 번역하고, 부족한 내용을 보충하여 작성한 글입니다. 이전에 보면 좋은 글: 도메인 주도 설계 도메인 주도 설계(DDD)사전 지식 - GRASP 패턴도메인 주도 설계(Domain-Driven Design) 란?도메인 주도 설계(Domain-Driven Design)는 소프트웨어의 핵심 비즈니스 도메인에 집중하여 복잡한 도메인 지식을 코드의 도메인 모델로 표dev.go-gradually.me 기초 지식 - 기능 요구사항 vs 비기능 요구사항기능 요구사항비즈니스 로직비기능 요구사항인프라 특성인프라 수준의 구현으로 해결해야 하는 요구사항성능, 품질, etc.DDD를 왜 쓰는가? → 소프트웨어 핵심에서 복잡성을 해결하는 것 DDD에는 흥미로운 트릴레마가 하나 존재..

개인적으로 SOLID 는 객체지향의 "기초" 라고 하기엔 너무 어렵다고 생각하지만, SOLID를 통해 객체지향 학습을 시작하는 사례가 많으니, SOLID를 이해하기 위한 흐름을 잡아 설명하도록 하겠다.1. 객체지향 프로그래밍의 기본 특성객체지향 프로그래밍은 소프트웨어 설계와 구현에 있어 효율성과 유지보수성을 높이기 위한 패러다임이다. 대표적인 네 가지 특성은 캡슐화, 상속, 다형성, 추상화이며, 각각 다음과 같이 설명할 수 있다.1.1 캡슐화캡슐화는 데이터(필드)와 그 데이터를 처리하는 메서드를 하나의 객체로 묶어, 외부에서 불필요하거나 민감한 정보에 직접 접근하지 못하도록 제한하는 개념이다. 이를 통해 객체 내부의 상태를 보호하고, 변경의 영향을 최소화할 수 있다. 1.2 상속상속은 기존의 클래스를 기..