nyambu 님의 블로그

1. 전통적인 CRUD 아키텍처의 한계1-1. 명령과 조회가 뒤엉킨 서비스 구조 전통적인 애플리케이션은 대부분 하나의 도메인 모델로 명령(Command)과 조회(Query)을 동시에 처리한다. 예를 들어 OrderService는 주문 생성과 동시에 주문 내역 조회도 담당하며, 이는 단일 모델로 모든 역할을 떠안는 구조다. 개발 초기에는 간단해 보일 수 있으나, 시간이 지나면 기능이 복잡해지고 데이터 처리 요구가 다양해지면서 코드의 응집도가 낮아지고 유지보수가 어려워진다. 게다가 명령과 조회는 설계 목표 자체가 다르다. 명령은 데이터 정합성과 비즈니스 규칙을 중심으로 설계되어야 하고, 조회는 성능과 응답 속도에 초점을 맞춰야 한다. 두 책임을 한 클래스가 동시에 지는 것은 단일 책임 원칙(SRP)을 위배..

1. 애그리거트의 핵심 역할1-1. 비즈니스 무결성을 보장하는 경계 애그리거트(Aggregate)는 도메인 주도 설계(DDD)에서 비즈니스 규칙의 일관성을 유지하는 최소 단위로 사용된다. 즉, 하나의 트랜잭션 안에서 상태 변경이 일어날 수 있는 객체의 범위를 정의한다. 여러 엔터티와 값 객체가 구성돼 있을 수 있지만, 외부에서는 루트 엔터티를 통해서만 조작 가능하다. 예를 들어 Order는 루트이고, 그 안에 OrderLine, ShippingInfo, PaymentInfo 등의 하위 객체가 있다. 외부에서는 직접 OrderLine을 수정할 수 없고, 반드시 Order를 통해 추가/삭제해야 한다. 이러한 구조는 객체 간 무결성을 유지하며, 변경 범위를 명확히 제한해준다. 결국 애그리거트는 단순한 객체 ..

1. 객체지향에서의 본질적인 구분1-1. 왜 두 개념이 필요한가? 소프트웨어 설계에서 모든 객체를 동일하게 취급하면, 코드가 복잡해지고 유지보수성이 떨어진다. 그래서 객체의 ‘역할’에 따라 개념적으로 구분하는 것이 중요하다. Value Object와 Entity의 구분은 바로 이 설계 명확성을 높이기 위한 핵심적인 전략이다. Value Object는 그 값 자체가 중요한 객체이고, Entity는 고유한 정체성을 가진 객체다. 동일한 데이터를 가진 두 객체라도, Value Object라면 하나로 취급되지만, Entity라면 각각 별개의 존재다. 이 구분이 없다면 동일성, 식별, 변경 추적 등의 이슈가 설계 전반에 영향을 미치게 된다. 이러한 구분은 단지 철학적 개념이 아니라, 모델링의 의도와 코딩 구현 ..

1. 도메인 주도 설계란 무엇인가?1-1. 복잡한 소프트웨어를 다루는 새로운 접근법 도메인 주도 설계(Domain-Driven Design, DDD)는 단순한 설계 기법이 아니라, 복잡한 비즈니스 요구사항을 명확히 모델링하고 지속적으로 진화시켜가는 방법론이다. 전통적인 시스템 설계는 기능 중심이었지만, DDD는 "비즈니스 개념을 코드에 반영한다"는 철학을 중심으로 한다. DDD는 에릭 에반스(Eric Evans)의 저서 『Domain-Driven Design』에서 처음 정립되었으며, 복잡한 도메인 로직을 개발자와 도메인 전문가가 공통 언어(Ubiquitous Language) 로 공유하며 점진적으로 모델링하는 방식이다. 즉, 비즈니스 언어를 모델로 승화시키는 과정이다. 이 철학은 단순히 객체지향을 더..

1. 행동 패턴이 필요한 이유1-1. 생성과 구조만으로는 부족하다 객체지향 설계에는 생성(Creational), 구조(Structural), 행동(Behavioral)이라는 세 가지 패턴 분류가 있다. 대부분의 초보 설계자들은 생성과 구조 패턴에 집중하는 경향이 있다. 하지만 객체가 생성되고 관계가 설정된 후, 실제 동작 방식의 유연성을 확보하는 것이 진짜 설계의 완성이다. 행동 패턴은 객체 간의 협력과 메시지 흐름을 설계하는 데 초점을 맞춘다. 이는 단순한 로직 분리 수준을 넘어, 시간에 따라 변화하거나 전략적으로 대체 가능한 행동을 추상화하는 방식으로 시스템의 복잡성을 줄인다. 특히 사용자 인터페이스, 이벤트 처리, 명령 실행 등에서 매우 유용하게 활용된다. 행동 패턴이 없다면 모든 행동은 if-..

1. 싱글턴 패턴의 본질과 한계1-1. 싱글턴은 왜 등장했을까? 객체지향 설계에서 싱글턴(Singleton)은 "클래스의 인스턴스를 단 하나만 생성하고, 어디서든 접근할 수 있도록 하는 패턴"이다. 이 패턴은 주로 다음 두 가지 상황에서 유용하다.애플리케이션 전체에서 공유 자원이 필요할 때하나의 인스턴스만 있어야 일관성을 유지할 수 있는 경우 예를 들어, 로그 기록기(Logger), 설정 객체(Config), DB 커넥션 풀(Connection Pool)처럼 애플리케이션 전체에서 동일한 인스턴스를 사용하는 것이 바람직한 경우 싱글턴이 사용되었다.public class Logger { private static final Logger instance = new Logger(); private L..

1. 객체 생성의 유연성을 위한 패턴들1-1. 생성 패턴이 중요한 이유 객체 지향 프로그래밍에서 가장 먼저 부딪히는 설계 과제가 바로 객체 생성이다. 언뜻 보면 단순한 new 연산자만으로 충분해 보이지만, 규모가 커질수록 이 단순한 생성 방식이 구조를 경직시키고 테스트를 어렵게 만든다. 예를 들어, 어떤 객체를 생성하려면 내부 구성 객체들도 같이 생성해야 하고, 그에 따른 환경 설정도 초기화해야 한다면, 생성자가 너무 복잡해지고 객체 간의 의존성이 코드 깊숙이 박히게 된다. 이런 상황에서 등장하는 것이 팩토리 패턴이다. 객체 생성 자체를 캡슐화하고, 클라이언트는 객체를 사용하는 데만 집중할 수 있도록 설계한다. 팩토리 패턴은 특히 확장 가능한 구조, 느슨한 결합, 의존성 주입의 유연성이라는 측면에서 필수..

1. 디자인 패턴이란 무엇인가?1-1. 소프트웨어 설계의 재사용 가능한 해법 디자인 패턴은 단순한 코드 템플릿이 아니다. 그것은 반복되는 문제에 대해 검증된 해결책을 구조화한 설계 전략이다. 건축에서 ‘문을 여닫기 위한 구조’, ‘복층 구조를 위한 계단’ 등의 해법이 있는 것처럼, 소프트웨어에도 문제가 생겼을 때 ‘이럴 땐 이렇게 푼다’는 공통된 해결 틀이 필요하다. 이러한 해결 틀을 공식화한 것이 바로 디자인 패턴이다. 실무에서는 특정한 상황에서 “이걸 어떻게 풀지?”보다, “이 문제는 전략 패턴으로 풀 수 있어”라고 생각하는 것이 설계자 수준의 사고다. 이처럼 디자인 패턴은 단순 구현이 아니라 설계 관점의 레벨을 높이는 도구다.1-2. 패턴은 왜 중요한가? 디자인 패턴의 핵심 가치는 공통 언어와 설..

1. 이론과 현실 사이의 간극1-1. SRP와 OCP는 언제 충돌하는가 SOLID 원칙은 객체지향 설계에서 이상적인 구조를 안내해주는 나침반 같은 존재다. 그러나 이상은 이상일 뿐, 실무에서는 그 원칙들이 충돌하거나 현실과 괴리되는 순간들이 적지 않다. 특히 SRP(단일 책임 원칙)과 OCP(개방-폐쇄 원칙)은 애초에 지향하는 방향 자체가 다르기 때문에 실제 개발 현장에서는 둘 사이의 갈등이 빈번히 발생한다. SRP는 책임을 명확하게 나누라고 하고, OCP는 기존 코드를 수정하지 말고 확장하라고 요구한다. 그런데 책임을 나누다 보면 단일 클래스가 너무 작아지고, 그 조합을 위한 코드가 중첩되며, 새로운 기능이 들어올 때마다 확장을 고려해야 하는 OCP와 상충하게 된다. 반대로, 확장을 위해 공통된 인터..

1. SOLID 원칙이란?1-1. 소프트웨어 설계의 5대 원칙 소프트웨어 개발에서 “잘 설계된 코드”란 과연 어떤 것일까? 유지보수가 쉽고, 변경에 유연하며, 재사용성이 높은 코드가 바로 그 기준이다. 이러한 이상적인 구조를 현실에서 구현하기 위해 등장한 개념이 바로 SOLID 원칙이다. SOLID는 객체지향 설계의 다섯 가지 핵심 원칙을 묶은 약어로, 각각의 원칙은 객체 간의 관계, 클래스의 역할, 모듈의 구조 등 전반적인 시스템의 견고함을 높이는 데 기여한다. 이 다섯 가지는 다음과 같다.S (SRP): 단일 책임 원칙 (Single Responsibility Principle)O (OCP): 개방-폐쇄 원칙 (Open/Closed Principle)L (LSP): 리스코프 치환 원칙 (Liskov..