스프링 프레임워크를 공부하며 프로젝트를 설계하는 도중 프로젝트 설계 과정에서 의외의 문제가 발생했었다. 기존에 만들었던 웹 프로젝트대로 Controller & Service & Domain & Repository 패키지를 생성해서 만들었지만 프로젝트를 설계하는 데에 있어서 분명히 설계 기준이 있을 거라는 생각이 들었다. 아니나 다를까 DDD이든 Layered 이든 여러 가지 프로젝트 아키텍처가 존재하는 것을 알게 되었고, 이번 기회에 상세히 정리해서 프로젝트에 구체적으로 적용시켜볼 생각이다.
소프트웨어 아키텍처(Software Architecture) 란?
-> 말 그대로 구조이다.
-> 여러 가지 소프트웨어 구성 요소가 가진 특성 중 외부에 드러나는 특성, 구성 요소 간의 관계를 표현하는 시스템 구조나 구조체
모듈
-> 소프트웨어를 구성하고 있는 작은 기능 하나의 단위
컴포넌트
-> 모듈을 기능별로 묶어 놓은 집합
=> 이 전체를 라이브러리라고 부른다.
이제 기본적인 용어들을 알아 보았으니 본격적으로 다루기 위한 아키텍처의 개념을 살펴보자
Layered Architecture
> 관심사의 분리(Seperation of concerns)에 따라 시스템을 유사한 책임(관심)을 지닌 Layer로 분리하고 각각의 Layer가 하위 Layer에만 의존하도록 구성하는 아키텍쳐 패턴
목적
> 각 레이어들이 특정 관심사와 관련된 개체만을 포함하도록 함
> 시스템의 결합도 낮춤
> 개발자의 인지 과부하 방지
> 이로 인한 재사용성 & 유지보수성 향상
계층
- Presentation layer : 사용자의 요청 및 응답을 담당
- Application layer : 애플리케이션의 흐름을 제어
- Domain layer : 도메인의 핵심 로직을 포함
- Infrastructure layer : 상위 계층을 지원
단점
- 프로젝트의 규모가 클 수록 확장성이 떨어짐
- 분리된 관심사 외에 다른 관심사가 발견된 경우 패키지 분리 및 코드 배치가 어려워짐
- 복잡한 비즈니스 논리를 해결하고 성능적 이점을 얻기가 어려움
적용하기 좋은 예
- 프로젝트 도메인이 복잡한 논리를 포함하지 않은 경우
- 확장성보다는 일관성을 가져가는 것이 목표인 경우
- 소규모로 구성된 팀인 경우
=> 개인적으로 개인 프로젝트 단계에서는 이 아키텍처를 가져가는 게 알맞겠다는 생각을 했다.
Domain Driven Development
> 도메인을 중심으로 설계해 나가는 것
도메인이란?
> 실세계에서 사건이 발생하는 집합
> ex ) 옷 쇼핑몰 : [주문하는 도메인, 옷을 관리하는 도메인, 건물 관리 도메인 등등등]
이러한 여러가지 도메인들이 서로 상호작용 하며, 설계하는 것이 바로 도메인 주도 설계
특징
> 서로 다른 도메인 영역에 영향을 끼치기 위해서는 API로 호출해야함
> 각각의 도메인은 서로 철저히 분리
> 이로 인한 높은 응집력과 낮은 결합도로 변경과 확장에 용이한 설계를 이룸
Domain Layer
> Entity (고유 식별자 [PK]를 바탕으로 객체의 정체성 부여), VO (상태 [Attribute] 를 바탕으로 객체의 정체성 부여) 를 활용하여 도메인 로직이 진행되는 계층
적용하기 좋은 예
- 프로젝트 도메인이 복잡한 논리를 포함한 경우
- 확장성을 가져가는 것이 목표인 경우
- 대규모로 구성된 팀인 경우
나의 프로젝트에는 어떤 아키텍쳐를 적용 시키는게 좋을까?
> 도메인 레이어, 애플리케이션 레이어 아키텍쳐의 개념을 공부한 결과 개인 프로젝트 같은 소규모 프로젝트는 application layer 기반 아키텍쳐를 사용하는 것이 맞다는 결론을 내렸다.
> 대규모성 확장성을 띈 프로젝트가 아니기 때문에 DDD는 나중에 회사에서 경험을 해보고 싶다.
참고: https://moo-you.tistory.com/218
소프트웨어 아키텍처(Software Architecture) 란?
소프트웨어 아키텍처(Software Architecture) 란? 개념적 의미 여러 가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중 외부에 드러나는 특성, 그리고 구성 요소 간의 관계를 표현하는 시스템 구
moo-you.tistory.com
참고: https://huisam.tistory.com/entry/DDD
DDD(Domain Driven Design) - 도메인 주도 설계란? 마이크로서비스의 관점에서
객체지향에서부터 도메인 주도 설계를 이해하기 위해서는 객체지향을 먼저 이해할 필요가 있습니다 객체지향에서의 핵심은 뭘까요? 객체지향에서의 핵심은 실세계의 객체(물건, 사람, 주문 ....
huisam.tistory.com
참고: https://happycloud-lee.tistory.com/94
DDD 핵심만 빠르게 이해하기
참고: https://steemit.com/kr/@frontalnh/domain-driven-design 위 글은 Eric Evans의 '도메인기반디자인'을 번역한 글인듯 한데 직역하다 보니 의미가 잘 전달 안되는 부분이 있어 제 나름대로 재해석하였습니다..
happycloud-lee.tistory.com
'🏛️ Architecture' 카테고리의 다른 글
| [만들면서 배우는 클린 아키텍처] Chapter10. 아키텍처 경계 강제하기 (0) | 2022.11.15 |
|---|---|
| [만들면서 배우는 클린 아키텍처] Chapter9. 애플리케이션 조립하기 (0) | 2022.11.11 |
| [만들면서 배우는 클린 아키텍처] Chapter6. 영속성 어댑터 구현하기 (0) | 2022.10.31 |
| [만들면서 배우는 클린 아키텍처] Chapter5. 웹 어댑터 구현하기 (0) | 2022.10.30 |
| 데이터 분산 처리 [Micro Service Architecture] (0) | 2022.05.27 |
