[항해99 취업 리부트 코스 학습일지] 28일차

이번 주 목표 

📢 이번주 목표는 도메인 주도 개발 시작하기 책 완독하기(78/357)

오늘 스케줄

09:00~13:00 역량 평가 문제 풀이
13:00~14:00 점심 식사
14:00~14:30 프로젝트 발제 듣기
14:30~17:00 코딩테스트 합격자 되기 책 읽기
17:30~18:00 팀 코드 선정 회의
18:30~18:50 기술매니저 님과 팀 코드 리뷰
18:50~17:50 저녁 식사
20:00~21:30 인프런 JPA 1편 강의 듣기
21:30~23:00 DDD 책 읽기
23:00~00:30 인프런 마이크로 서비스 강의 듣기

오늘 목표

👉 역량 평가 4문제 모두 풀기

👉 TIL 빠지지 않고 작성하기

👉 북 스터디 참여

👉 인프런 마이크로서비스 강의 수강하기

👉 JPA 1편 강의 듣기

👉 DDD책 읽기

👉 정보처리산업기사 실기 준비

오늘 한 것

• 역량 평가 4문제 풀기
• TIL 빠지지 않고 작성하기
• 북 스터디 참여
• 인프런 마이크로 서비스 강의 듣기
• JPA 1편 강의 듣기
• DDD 책 읽기

오늘 못한 것

• 정보처리산업기사 실기 준비

알게된 것

DDD(Domain-Driven Design)란?

도메인 주도 설계(Domain-Driven Design, DDD)란 소프트웨어를 특정 도메인과 일치하도록 모델링하는 것으로, DDD는 비즈니스 도메인의 개념과 용어를 소프트웨어 코드의 구조와 언어로 표현하여 개발 과정에서 도메인 전문가와 개발자 사이의 의사 소통을 원활하게 하고, 도메인 지식을 더 잘 반영할 수 있도록 합니다.

 

DDD의 한 가지 중요한 특징은 소프트웨어 코드의 구조와 언어가 비즈니스 도메인의 용어와 일치한다는 점입니다. 예를 들어, 대출 응용 프로그램을 개발한다고 가정해보면, 소프트웨어 코드에는 "LoanApplication"과 "Customer"와 같은 클래스, "AcceptOffer"와 "Withdraw"와 같은 메소드가 있을 수 있습니다. 이렇게 함으로써 비즈니스 도메인 전문가와 개발자는 동일한 용어를 사용하며 의사 소통할 수 있으며, 소프트웨어는 실제 비즈니스 도메인을 잘 반영하게 됩니다.

 

DDD는 지속적으로 발전하는 모델의 구현에 초점을 맞춥니다. 즉, 도메인 모델은 초기에 설계되고 구현되지만 도메인의 복잡성과 요구사항의 변경에 따라 계속해서 발전하고 개선됩니다. DDD는 도메인 전문가와 개발자가 함께 도메인을 탐구하고 모델을 개선하며 도메인의 핵심 개념과 도메인 객체들 간의 관계를 명확하게 이해하는 데 도움을 줍니다. 이를 통해 소프트웨어 시스템이 비즈니스 도메인의 복잡성을 잘 다루고 유연하게 대응할 수 있습니다.

 

DDD는 비즈니스 도메인에 집중하고 도메인 모델을 중심으로 개발을 진행함으로써 소프트웨어의 복잡성을 줄이고 유지보수성을 향상시킬 수 있는 장점을 가지고 있습니다. 또한, 도메인 주도 설계는 마이크로서비스 아키텍처와 함께 사용될 때 특히 유용하며, 비즈니스 도메인을 기반으로 서비스를 분리하고 개별적으로 개발하고 배포할 수 있는 이점을 제공합니다.

 

DDD의 원칙과 패턴

도메인 주도 설계는 도메인의 복잡성을 다루기 위해 다양한 원칙과 패턴을 제공하는데, 이에 대해 자세히 설명하겠습니다.

유비쿼터스 랭귀지 (Ubiquitous Language)

유비쿼터스 랭귀지는 도메인에 대해 모든 관계자가 공통으로 사용하는 언어입니다. 코드, 문서, 대화 등 모든 커뮤니케이션에서 일관되게 사용되어야 하며 유비쿼터스 랭귀지를 사용함으로써 도메인 지식을 공유하고, 오해를 줄이며, 협업을 촉진할 수 있습니다.

애그리거트 (Aggregate)

애그리거트는 서로 관련된 도메인 객체들의 묶음으로, 하나의 루트 엔티티를 가지고 루트 엔티티를 통해서만 다른 객체에 접근할 수 있습니다. 애그리거트는 일관성을 유지하기 위해 경계를 정하고 불변식을 지키는데, 이는 도메인 모델의 중요한 구성 요소로 도메인 객체들 간의 관계와 상호작용을 명확하게 정의하고 제한함으로써 도메인의 복잡성을 다룰 수 있습니다.

도메인 서비스 (Domain Service)

도메인 서비스는 엔티티나 값 객체로 표현하기 어려운 도메인 로직을 수행하는 서비스입니다. 도메인 서비스는 상태를 가지지 않으며, 파라미터로 엔티티나 값 객체를 받아서 결과를 반환합니다. 또한 비즈니스 로직을 명확하게 구현하고 중복을 줄이며 응집도를 높이는 역할을 합니다. 이를 통해 도메인 모델에 표현하기 어려운 복잡한 도메인 로직을 분리하고 도메인 객체들 간의 의존성을 관리할 수 있습니다.

리포지토리 (Repository)

리포지토리는 애그리거트의 영속성을 관리하는 저장소로 애그리거트의 생성, 조회, 수정, 삭제 등의 기능을 제공합니다. 리포지토리는 인터페이스와 구현으로 분리되어야 하며, 구현은 메모리, 데이터베이스, 파일 등 다양한 방식으로 이루어질 수 있습니다. 리포지토리를 사용하여 도메인 객체들을 영속화하고, 검색 및 조작할 수 있으며, 도메인 객체의 상태를 관리할 수 있습니다.

도메인 주도 설계의 장점

비즈니스 도메인에 집중: DDD는 비즈니스 도메인을 중심으로 개발을 진행하는 방법론입니다. 개발자들은 도메인 전문가와 긴밀한 협력을 통해 비즈니스 도메인에 대한 이해를 깊이 있게 할 수 있습니다. 이는 개발자들이 비즈니스 도메인의 복잡성을 이해하고 실제 요구사항을 반영하는 소프트웨어를 개발할 수 있도록 돕습니다.

 

의사소통과 협업의 강화: DDD는 도메인 전문가와 개발자 간의 의사소통과 협업을 강화합니다. 비즈니스 도메인의 용어와 개념을 코드에 반영함으로써, 비즈니스 전문가와 개발자는 동일한 언어를 사용하여 서로간의 의사소통을 원활하게 할 수 있습니다. 이는 비즈니스 요구사항을 명확하게 이해하고, 개발자들이 올바른 솔루션을 제공할 수 있도록 돕습니다.

 

유연하고 확장 가능한 설계: DDD는 모델 주도 설계를 강조하므로, 소프트웨어 설계는 비즈니스 도메인 모델을 중심으로 이루어집니다. 이는 소프트웨어가 비즈니스 도메인을 잘 반영하고, 도메인의 복잡성을 다룰 수 있도록 합니다. 또한 도메인 모델은 지속적으로 발전하고 개선될 수 있으므로, 소프트웨어 시스템이 변화하는 요구사항에 유연하게 대응할 수 있습니다.

 

복잡성 관리: DDD는 복잡한 비즈니스 도메인을 모델링하는데 도움을 줍니다. 도메인 모델은 도메인의 핵심 개념과 규칙을 표현하므로 복잡한 비즈니스 도메인을 단순하고 이해하기 쉬운 구조로 변환할 수 있습니다. 이는 개발자들이 복잡성을 이해하고 제어하는데 도움을 주며 유지보수성을 향상시킵니다.

 

품질 향상: DDD는 품질을 중요시하는 설계 원칙과 기법을 제공합니다. 도메인 모델을 통해 비즈니스 도메인의 핵심 개념과 규칙을 명확하게 표현할 수 있으며, 이를 기반으로 한 테스트 가능한 코드를 작성할 수 있습니다. 또한 DDD는 도메인 모델에 대한 테스트를 지원하는 다양한 도구와 패턴을 제공하여 품질 관리를 강화합니다.

 

마이크로서비스 아키텍처와의 결합: DDD는 마이크로서비스 아키텍처와 자연스럽게 결합됩니다. 비즈니스 도메인을 기반으로 서비스를 분리하고 개별적으로 개발하고 배포함으로써, 마이크로서비스 아키텍처의 이점을 최대화할 수 있습니다. DDD는 마이크로서비스 간의 경계 설정과 상호작용을 명확하게 정의하고, 각 서비스를 독립적으로 발전시킬 수 있는 구조를 제공합니다.

 

도메인 주도 설계의 단점

학습 곡선과 복잡성: DDD는 상대적으로 복잡한 개념과 패턴을 포함하고 있어 학습 곡선이 가파를 수 있습니다. 새로운 개념과 용어를 이해하고 적용하는 데 시간이 걸릴 수 있으며, 초기에는 설계 및 구현에 대한 추가적인 노력과 복잡성이 발생할 수 있습니다. 이는 팀의 경험 수준에 따라 영향을 받을 수 있습니다.

 

과도한 추상화: DDD는 도메인의 복잡성을 다루기 위해 추상화를 사용합니다. 하지만 과도한 추상화는 코드의 이해를 어렵게 하고 개발자들이 복잡한 구조를 해석하고 유지보수하는 데 어려움을 줄 수 있습니다. 잘못된 추상화는 오히려 코드의 가독성을 저하시킬 수 있습니다.

 

초기 비용과 시간: DDD는 비즈니스 도메인에 집중하는 설계 방법론으로, 초기에 도메인 모델을 개발하고 도메인 전문가와의 협업을 강조합니다. 이는 초기 개발 비용과 시간을 증가시킬 수 있는데 특히, 도메인의 복잡성이 큰 경우에는 초기 분석과 설계에 많은 시간과 노력이 필요할 수 있습니다.

 

팀 구성과 조직적인 도입 난이도: DDD는 도메인 전문가와 개발자 간의 협업을 강조하므로 팀의 구성이 중요합니다. 도메인 전문가와 개발자가 적절한 수준으로 협력하지 않는다면 DDD의 장점을 충분히 활용하기 어려울 수 있습니다. 또한 기존 조직에서 DDD를 도입하려면 조직 문화와 프로세스의 변경이 필요할 수 있으며 이는 도입 난이도를 높일 수 있습니다.

 

오용과 오버 엔지니어링: DDD는 강력한 도구이지만 오용하면 과도한 복잡성과 오버 엔지니어링으로 이어질 수 있습니다. 적절한 상황과 도메인의 복잡성을 고려하지 않고 과도하게 DDD를 적용하면 개발 프로젝트의 비용과 일정을 증가시키고, 유지보수성을 저하시킬 수 있습니다. DDD는 적절한 규모와 범위에서 적용해야 합니다.

 

기술 종속성: DDD는 도메인 중심의 설계 방법론이지만, 특정 기술과 밀접하게 연결될 수 있습니다. 특히, DDD와 ORM(Object-Relational Mapping) 프레임워크를 함께 사용할 경우 기술 종속성이 커질 수 있습니다. 이는 기술 스택 변경이 어려워지고, 다른 환경에서의 적용이 제한될 수 있다는 점을 의미합니다.

 

정리

도메인 주도 설계(Domain-Driven Design, DDD)는 비즈니스 도메인에 집중하고 복잡성을 다루기 위한 강력한 설계 방법론입니다. DDD는 소프트웨어를 비즈니스 요구사항과 도메인 지식에 밀접하게 맞추어 개발하는데 중점을 두며, 유비쿼터스 랭귀지, 애그리거트, 도메인 서비스, 리포지토리 등 다양한 원칙과 패턴을 제공합니다.

 

이를 통해 DDD는 비즈니스 도메인의 이해와 소통을 강화하고, 개발자와 도메인 전문가 간의 협업을 원활하게 도모합니다. DDD는 복잡한 도메인을 모델링하고 관리하는데 도움을 주며, 유연하고 유지보수 가능한 소프트웨어를 개발하는 데 도움이 됩니다.

 

하지만 DDD도 완벽하지는 않습니다. 학습 곡선이 가파르고 초기 비용과 시간이 소요될 수 있으며 과도한 추상화와 오용으로 인해 코드의 복잡성이 증가할 수도 있습니다. 또한 팀 구성과 조직적인 도입 난이도, 기술 종속성 등의 문제점도 있을 수 있습니다.

 

DDD의 성공적인 도입을 위해서는 팀의 역량과 조직 문화의 지원이 중요하며 상황과 프로젝트 특성을 고려하여 적절한 범위와 규모로 DDD를 적용해야 합니다. 항상 실용성과 목표를 유지하면서 DDD를 적용하고, 도메인 모델을 지속적으로 발전시키는 데 집중해야 합니다.

 

DDD는 비즈니스 도메인을 중심으로 소프트웨어를 개발하고 유지보수하는 데 도움을 주는 강력한 도구입니다. 올바르게 이해하고 적용한다면 DDD는 소프트웨어 시스템의 품질과 유연성을 향상시키고 비즈니스 요구사항을 보다 효과적으로 충족시킬 수 있습니다.

출처: https://tech1.tistory.com/93

🤔오늘의 반성

- TIL 늦게 씀
- 실기 얼마 안남았는데 준비를 못함..

 

👍 오늘의 칭찬

1. 깃헙 1일 1커밋 달성
2. 북 스터디 참여
3. 역량 평가 4문제 모두 품
4. 그래도 오늘 하루 열심히 살았다...

❗ 항해99 취업 리부트 코스를 수강하고 작성한 콘텐츠 입니다.
https://hanghae99.spartacodingclub.kr/reboot