Architecture

❐ Description도메인 주도 설계(에릭 에반스) 14장 내용 중 Bounded Context를 읽고 요약한 글이다.   ❐ Bounded Context1. Bounded Context란?Bounded Context는 규모가 큰 프로젝트에서 여러 개의 도메인이 공존할 때 각 도메인의 경계를명확히 구분하는 개념이다.   2. 왜 Bounded Context가 필요한가?규모가 큰 프로젝트에서는 여러 개의 모델이 존재하며, 팀마다 다르게 해석할 여지가 있다.동일한 시스템을 개발하는 팀이 서로 다른 모델을 적용하면 혼란이 발생할 수 있다.명확한 경계를 정의하지 않으면, 팀 간 모델 차리를 빠르게 인지하기 어렵다. 결과적으로 예상치 못한 시스템 오류가 발생할 가능성이 높다.  3. 바운디드 컨텍스트의 핵심 ..

❐ Description이번 장은 앞선 내용들을 활용한 실습 예제를 살펴보는 장이다.이번 장 내용중 `새로운 기능 도입 : 할당량 검사` 파트만 간단하게 정리해보자.    ❐ 새로운 기능 도입 : 할당량 검사요약하자면, 기존에 존재하는 `해운 모듈`에 `영업 관리 시스템`을 통합하는 것이다.`영업 관리 시스템`은 `해운 모듈`에 존재하는 도메인 모델을 염두해두고 만든 것이 아니기 때문에,Booking Application에서 `영업 관리 시스템`를 수용하게 되면, 결합도가 높아지고 유지 보수가 어려워진다.그럼 어떻게 서로 다른 모델을 가진, 두 모듈을 유연하게 통합할 수 있을까? 책에서는 Anti Corruption Layer(오류 방지 계층)를 소개해주고 있다.약간 Adapater Pattern과 유사..

❐ Description도메인 주도 설계의 목표는 기술보다는 도메인에 대한 모델에 집중해 더 나은 소프트웨어를 만드는 것"에릭 에반스 - 도메인 주도 설계" 6장의 Repository 내용 정리.여기서 만든 예제는 스스로 이해를 돕기 위해 만든 간단한 예제.저장된 객체를 가져오는 것은 실제로는 생성의 한 부분집합Entity의 생명주기 가운데 중간 단계에 불과     ❐ 필요한 데이터를 직접 획득해서 조작하면 안된다.우선 여기서 가장 중요하게 설명하는 것은 아래와 같다. 클라이언트 코드에서 직접적으로 데이터베이스를 사용해서 Aggregate나 캡슐화와 같은특징을 활용하는 것을 우회하려고 하고, 그 대신 필요한 데이터를 직접 획득해서 조작하면 안된다. 아래와 같이 하지말라는 것이다.// 클라이언트 코드pub..

❐ Description"에릭 에반스 - 도메인 주도 설계" 6장의 Factory 내용 정리.여기서 만든 예제는 스스로 이해를 돕기 위해 만든 간단한 예제.     ❐ Factory와 Factory의 위치 선정1. Aggregate 내부 Factory MethodAggregate의 루트 엔티티에 팩토리 메서드를 배치하면, Aggregate의 무결성을 보장하는 책임을 루트가담당하게 된다.public class PurchaseOrder { private final String orderId; private final List items; // 생성자 생략 // ... // FACTORY METHOD: PurchaseItem을 생성하고 Aggregate에 추가 p..

❐ DescriptionWewoot 프로젝트를 하면서 DDD를 접했었다. 그 당시에는 빠른 실무 적용을 위해 "도메인 주도 개발 시작하기" 책을 통해서 스터디를 했고, 프로젝트에 점진적으로 적용해 나아갔다.아무래도 JPA 기반으로 설명이 되어 있다보니 적용이 수훨했다.  요즘 내 눈에는 MSA라는 단어가 많이 보인다. 아무래도 경력직 공고를 보다보니 그런 것 같다.그러다보니 DDD라는 설계에 꽂히게 됐다. 그리고 개인적으로 도메인들을 잘 쪼개놓고 그것이기대하는대로 동작하는 것을 보면 왠지 모르게 기분이 좋다. 그래서 이번에는 좀 더 깊에 DDD를 공부해보고자 "에릭 에반스 - 도메인 주도 설계"를 읽으면서DDD에 대한 지식의 깊이를 더 해보려고 한다. 후기를 보니 난이도도 높은데 번역이 쫌 자연스럽지 않..

❒ Description 이전 직장에서 진행했던 wewoot은 Monolithic 프로젝트였다. 물론 각 클래스 파일들은 각자의 역할에 맞는디렉토리에 위치해 있었다. 하지만 여기서 문제는 admin이 였는데, Admin-api와 Was-api가 섞여 있는 구조였다.이런 구조에서 admin을 배포하든, was를 배포하든 결국 프로젝트 내 모든 파일들을 대상으로 빌드가 이루어졌다. 위의 문제를 해결하기 위해 더 나은 설계가 있는지 찾아보다가 멀티 모듈이라는 것에 알게되었고, 해당 구조를wewoot에 적용을 하면 보다 나은 프로젝트 구조가 잡힐 것 같다는 생각이 들었다.  이번 기회에 궁금증들을 해결하고 아래의 내용들을 학습해 볼 예정이다.‣ 멀티모듈과 디렉토리의 차이는?‣ 멀티 모듈은 필수인가?‣ 구분 기준..