DDD

DDD, 어그리게이트 분리를 위한 리팩토링

[refactor/#119] DDD를 지키도록 게시글 도메인과 메뉴 도메인 분리 by Dong-Hyeon-Yu · Pull Request #120 · Inha 게시글 엔티티가 메뉴 엔티티를 직접 참조하고 있었는데, 두 개의 어그리게이트를 분리하기 위해서 MenuId 를 참조하도록 함. 단, @EmbeddedId 와 @GeneratedValue 는 동시에 사용할 수 없는 문제가 있음. ( github.com [refactor/#115] DDD 를 지키도록 회원 도메인과 게시판 도메인 분리 by Dong-Hyeon-Yu · Pull Request #117 · Inh 게시판 엔티티가 회원 엔티티를 직접 참조하는 것이 아니라, 회원 엔티티 ID 를 참조하도록 하여, 두 어그리게이트를 분리시킨다. MemberId..

[도메인 주도 설계 철저 입문] 12. 도메인의 규칙을 지키는 "어그리게이트"

어그리게이트란? 여러 객체가 모여 한가지 의미를 갖는 하나의 객체가 될 때, 이를 어그리게이트라고 할 수 있다. 어그리게이트는 경계와 루트를 갖는다. 루트는 어그리게이트 내의 특정한 객체인데, 외부에서 어그리게이트를 다루는 모든 조작은 루트를 거쳐야만 한다. 어그리게이트에 포함되는 객체를 외부에 노출하지 않음으로써 객체를 안전하게 다룰 수 있다. 객체를 다루는 기본 원칙 질서 없이 어그리게이트 내의 객체들을 다루게 되면, 객체의 논리적 일관성을 유지하기가 어렵다. UserName userName = new UserName("gildong"); user.name = userName; // 바람직하지 않은 변경 시도 user.changeName(userName); // ok 위와 같이 사용자의 이름을 변경 ..

[도메인 주도 설계 철저 입문] 10. 데이터의 무결성 유지하기

무결성이란 : 정보가 서로 모순이 없고 일관적이라는 뜻. 무결성 위배되는 경우 : 사용자 중복 검사를 시행할 때, 사용자 A 가 회원 등록 시도 => 중복 검사 => 중복되지 않음! (사용자 A 의 회원 등록이 db 에 적용되기 전) 사용자 B 가 동일한 회원 등록 시도 => 중복검사 => 중복 안됨! 사용자 A 의 회원 정보 저장 사용자 B 가 A와 동일한 회원 정보 저장 데이터 무결성을 지키는 방법 1. 유일 키 제약 : 가장 강력한 수단이지만, 코드 상으로 드러나지 않고 비지니스 코드가 db 에 의존적이라는 단점이 존재. 트랜젝션과 함께 사용하는 것이 좋다. 2. 트랜젝션 1. db 트랜젝션 객체 이용 : 아래 코드는 트랜잭션 코드를 통해 무결성을 확보한다. 하지만 이 경우에는 인프라 객체인 con..

[도메인 주도 설계 철저 입문] 6. 어플리케이션 서비스 - 도메인 서비스와의 분리!

이 글을 읽고 깨달아,, 적용한 커밋. 아래 PR 중에 있다. [refactor/member] 회원 서비스 리팩토링 by Dong-Hyeon-Yu · Pull Request #94 · InhaBas/Inhabas.com-api 학년 정보 없애기 학기 -> 기수 중복검사로직을 도메인 영역으로 분리 (링크) 회원가입 서비스 리팩토링 회원종류 생성 #93 회원가입 가능 기간 및 인터뷰 기간 db 설정 기능 추가 팀 생성 #77 resolve github.com 이 책에서 말하는 서비스는 크게 두가지로 나뉘는 듯 하다. 하나는 도메인 서비스, 다른 하나는 어플리케이션 서비스. 도메인의 특성에 관한 활동은 도메인 서비스. 클라이언트에게 제공할 UseCase 에 대한 활동은 어플리케이션 서비스. 기존에는 layer..

[Spring boot] 5. 멀티모듈? MSA? 좋은 아키텍쳐가 뭐야?!

프로젝트 구조 변경을 고민하게 된 배경이 몇가지 있다. (1) layer 는 구분이 가지만, 파일이 많아져서 해당 layer 안의 특정 도메인을 한눈에 찾기가 어려워지고 있다. 또 그렇다보니 어떤 도메인 모델이 어떤 service 와 controller 로 이어지는지 알기도 힘들어질 것 같았다. 특히 새로운 개발자가 들어왔을때는 확실히 눈에 안보일 거 같았다. (2) 또 파일 업로드 및 다운로드를 동료 개발자가 맡아서 처리하고 있는데, 해당 기능은 완전히 독립적인 서비스로 빠져도 될 것 같다는 생각이 들었다. (원격 서버에 실제 파일을 업로드하고 다운로드 하게 해주는 파일 서버). 같은 모듈 내에 있는 것보다는, 적어도 다른 모듈로 독립적으로 구성할 필요가 있다. (3) 빅데이터 및 ML 동아리이기 때문..

[도메인 주도 설계 철저 입문] 5. 레파지토리 - 데이터와 관계된 처리를 분리하자

프로그램을 실행할 때, 메모리에 로드된 데이터는 프로그램을 종료하면 그대로 사라져버린다. 특히 엔티티는 생애주기를 갖는 개체이기 때문에 프로그램의 종료와 함께 사라지면 안된다. 이를 위해서는 데이터를 데이터스토어에 저장하고 불러올 수 있어야한다. 데이터스토어로부터 불러오고, 저장하는 등의 행위를 추상화한 객체가 레파지토리 객체이다. 레파지토리의 역할과 책임 이 레파지토리 객체는 도메인 개념으로부터 유래한 것이 아니라, 기술적 문제를 해결하기 위해 탄생한 객체이다. 따라서 도메인을 잘 서술한 코드를 헤집어놓지 않으면서, 기술적 코드를 잘 분리해는 역할을 담당한다고 볼 수 있다. 특히 특정 db 에 의존적일 수 밖에 없는데, 이 때문에 더 다루기 까다롭게 되는 코드가 되어버릴 때가 많다. 그래서 레파지토리 ..

[도메인 주도 설계 철저 입문] 4. 도메인 서비스 - 부자연스러운 도메인 객체의 행동을 맡기자

값 객체나, 엔티티 같은 도메인 객체에는 객체의 행동읠 정의할 수 있다. 예를 들어 사용장명으로 사욯라 수 잇는 문자열의 길이나 문자의 종류에 제한이 있다며 ㄴㅇ이런한 지식은 사용자명을 나타내는 값 객체에 정의할 수 있다. 근데 시스템에는 도메인 객체로 구현하기 어색한 행동도 있다. 도메인 서비스는 이런 어색함을 해결해주는 객체다. 예를 들어 사용자 이름 중복 여부 기능을 추가한다고 하자. 이 코드를 User 라는 도메인 객체에 추가하게 된다면 아래와 같이 할 수 있다. class User { private UserId id; private UserName name; public User(Integer id, String name) { if (Objects.isNull(id) || Objects.isNu..

[도메인 주도 설계 철저 입문] 3. 엔티티 - 생애주기를 갖는 객체

도메인 주도 개발에서 말하는 엔티티는 도메인 모델을 구현한 도메인 객체를 의미한다. 이전 장에서 다뤘던 값 객체도 도메인 객체를 의미한다. 값 객체와 엔티티의 차이점 값 객체와 엔티티의 차이점은 "동일성"을 식별할 수 있는지에 달려있다. 예를 들어 값 객체는 이름, 학년 등의 특정 성질을 띄는 값을 캡슐화한 것이라면, 엔티티는 회원을 예로 들 수 있다. 값 객체는 변하지 않는 값이고 (수정이 아닌 새로 생성, premitive type 을 예로 들면 쉬울 듯) 엔티티는 수정 가능하다. 또 속성이 같아도 다른 엔티티일 수 있는데 예로 같은 이름값이어도 다른 사람일 수 있는 것처럼 말이다. 따라서 엔티티를 식별할 수 있는 고유필드가 필요한데, 사람의 경우는 주민등록번호 등이 될 수 있다. 개발을 할 때, 이..