ddd 썸네일형 리스트형 DDD 기반의 AOP에서 비즈니스 로직이 가지는 의미 AOP(Aspect Oriented Programming, 관점 지향 프로그래밍)에서 중심적 관심사(Primary Concerns)는 횡단적 관심사(Crosscutting Concerns)와 대비되는 개념으로, 중심적 관심사는 해당 소프트웨어의 존재 목적으로서 소프트웨어를 통해 해결하고자 하는 현실세계의 문제를 뜻한다. DDD(Domain Driven Design, 도메인 주도 설계)를 통해 중심적 관심사를 도메인(영역) 별로 분류하고, 각각의 도메인을 해결하기 위한 의사결정을 수행하는 로직이 비즈니스 로직이다. 반면 중심적 관심사의 원활한 처리와 가공을 위한 횡단적 관심사의 반복적인 처리는 최소화하기 위해, annotation(외부 소프트웨어에 처리 내용을 지시하는 명령)을 활용하여 최대한 spring.. 더보기 DDD에서 Controller, Service, Repository의 역할 Layered Architecture는 애플리케이션의 컴포넌트(component, 구성요소)들을 계층(layer) 별로 나눈 구조이다. 일반적으로 presentation layer(Controller 컴포넌트가 속함), business(service) layer(Service 컴포넌트가 속함), data access layer(Repository 컴포넌트가 속함)의 세 개의 계층으로 나뉜다. 설계에 따라 네 개의 계층으로 나뉘기도 하고, Service와 Repository 컴포넌트가 함께 domain layer에 속하기도 한다. 이렇게 계층별로 나뉘는 구조의 대표적인 특징은 다음과 같다. 각 계층은 자신의 바로 하위 계층의 의존성을 주입받는다. 상위 계층에서 하위 계층으로만 접근이 가능하고, 역으로는 접.. 더보기 DDD(Domain Driven Design)에서 Entity, DTO, VO 비교 Entity Entity는 주로 데이터베이스의 테이블과 매핑되는 객체다. 값이 쉽게 변경되면 객체의 일관성이 유지되지 않으며 다른 객체들에도 영향을 끼치게 되므로, Setter가 아닌 생성자를 사용하는 것이 바람직하며 데이터 전송용으로는 적합하지 않다. Entity는 Business layer에 속하지는 않지만, 도메인에 관계되는 일부 복잡한 로직은 DDD의 Rich Model 개념에 의거하여 Entity에서 구현할 수도 있다. 이는 Entity가 스스로의 상태를 관리하기 위함이다. 하지만 이것이 주 목적은 될 수 없으며, 기본적으로는 데이터베이스의 조작을 수행하기 위한 매개체로서 기능한다. Entity 객체는 식별성을 가지고 있으므로, 반드시 식별자(ID)를 포함해야 한다. @Entity @Getter.. 더보기 DDD(Domain Driven Design)와 SQL 중심 설계의 차이점 DDD DDD(도메인 주도 설계)는 데이터를 도메인별로 나누어, 도메인 객체를 중심으로 관리하는 설계 기법이다. 여기서 도메인이란 현실 세계에서 해결해야 할 문제가 나눠지는 영역을 뜻한다. DDD 방식은 복잡한 비즈니스 로직을 가지는 소프트웨어에 적합하며, 비즈니스의 요구사항을 보다 명확하게 이해하고, 이를 개발자의 코드에 반영할 수 있도록 돕는다. 도메인 주도 설계를 통해 객체의 역할을 명확히 구분할 수 있고, 비즈니스 로직(현실세계의 문제(도메인)에 대한 의사결정 과정을 포함하는 로직)과 서비스 로직(애플리케이션의 기능을 지원하는 로직)이 구별되어 주요 문제에 집중하기 쉬워진다. 비즈니스와 서비스 객체의 구분이 명확하므로 유지 보수가 용이하고, 도메인별 연관관계 속에서 데이터가 관리되므로 체계적인 관.. 더보기 이전 1 다음