본문 바로가기

Development

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 방식은 복잡한 비즈니스 로직을 가지는 소프트웨어에 적합하며, 비즈니스의 요구사항을 보다 명확하게 이해하고, 이를 개발자의 코드에 반영할 수 있도록 돕는다. 도메인 주도 설계를 통해 객체의 역할을 명확히 구분할 수 있고, 비즈니스 로직(현실세계의 문제(도메인)에 대한 의사결정 과정을 포함하는 로직)과 서비스 로직(애플리케이션의 기능을 지원하는 로직)이 구별되어 주요 문제에 집중하기 쉬워진다. 비즈니스와 서비스 객체의 구분이 명확하므로 유지 보수가 용이하고, 도메인별 연관관계 속에서 데이터가 관리되므로 체계적인 관.. 더보기
Spring Framework의 DI(의존성 주입)와 IoC(제어의 역전) 개념 정리 DI DI(의존성 주입)는 클라이언트(다른 객체를 사용하려는 대상)가 의존할 객체를 외부에서 지정해 주는 것을 말한다. 역할이 배타적이지 않고 다른 객체의 변화에 영향받는다면 의존성이 있는 것이다. 클라이언트가 직접 객체를 생성하지 않아도, IoC(DI) Container를 통해 객체를 관리하는 spring framework는 다른 객체에 의존하도록 주입할 수 있다. IoC Container는 객체 생성 대상으로 지정된 객체를 관리하며 자동으로 객체를 생성하고, annotation을 통해 클라이언트의 코드 변경 없이 다형성을 구현할 수 있게 해 준다. 이는 클라이언트가 아닌 프레임워크가 제어 권한을 갖고 있기 때문에 가능한 것이다. IoC IoC(제어의 역전)는 프로그램의 제어 권한이 뒤바뀌는(inver.. 더보기
내가 자주 이용하는 웹사이트 : 나무위키 나무위키는 다수의 이용자들이 각종 정보를 게시하는 위키 사이트다. 나무위키의 전신이라고 할 수 있는 리그베다 위키 시절부터 10년 넘게 사이트를 이용해 왔다. 나무위키는 누구나 문서를 작성할 수 있기 때문에, 재미있는 정보들뿐만 아니라 다양한 분야의 전문가들이 작성한 전문 지식도 습득할 수 있다. 다만 누구나 작성/편집할 수 있는 만큼 문서 훼손 행위의 위험성이 있기 때문에, 일부 문서는 로그인 사용자만 편집 가능하거나 편집이 불가능하게 제한하는 기능이 있다. 이용자들의 기여를 통해 사이트를 발전시켜 나가면서도 일정 수준 이상의 품질을 유지하기 위한 좋은 수단으로 생각된다. 단점으로는 누구나 자유롭게 편집할 수 있기 때문에, 문서의 공신력이 떨어지는 편이다. 정보가 부정확하거나 작성자 개인의 주관이 많이.. 더보기
collection framework의 interface(List, Set, Map)별 주요 method 정리 공식문서에서는 method에 대해 서술할 때 타입을 일일이 설명해 주기 때문에 직관적으로 외우기 불편하다. 그래서 이곳에 내가 기억하기 편한 방식으로 정리해 두려 한다. 각 구현 클래스들에 관한 것은 시간이 된다면 다음 포스팅에서 다룰 예정이다. '이것이 자바다' 교재를 통해 공부한 내용과 개인적인 이해방식을 바탕으로 작성했으므로 틀린 내용이 있을 수 있다. List와 Set은 Collection 인터페이스를 상속하는 자식 인터페이스이고, Map은 독립(POJO) 인터페이스이다. 셋 다 java.util 패키지에 속해 있으므로, 사용하려면 인터페이스를 가져오는(import) 작업이 필요하다. List List는 index 순서대로 저장하는 방식이다. 다른 index에 같은 내용의 객체를 중복 저장할 수 .. 더보기
method overriding 과정에서 @Override annotation을 사용해야 하는 이유 method overriding(메소드 재정의)은 부모 클래스에게 method를 상속받은 자식 클래스 또는 인터페이스를 구현한 구현 클래스에서, 해당 클래스에 적합하지 않거나 별개의 작업이 필요한 부모 클래스의 메소드 실행내용을 변경해 적용하는 작업이다. 이를 통해 같은 클래스를 상속받거나 구현한 클래스 간에도 다형성을 구현할 수 있다. 또한 추상 메소드(abstract method)는 실행부가 존재하지 않으므로, 반드시 재정의가 필요하다. 어제 포스팅한 객체의 네 가지 특성 중 상속성 항목의 마지막에 @Override annotation에 대해 간략하게 언급했었다. 클래스 상속 후 메소드를 재정의할 때, 자식 클래스에서는 해당 메소드의 선언부를 부모 클래스의 메소드 선언부와 동일하게 작성해야 한다. 또.. 더보기

티스토리툴바