패스트캠퍼스 캐시백 챌린지 16일차

 

 

수강 인증샷

Monolithic Architecture과 Microservice Architecture에 관한 클립과 DDD에 대한 클립을 복습하고 새로운 클립을 수강하는식으로 챌린지를 진행하였다. 대게 초기에 서비스도입을 결정할때에는 monolithic으로 빠르게 개발하였다가 개발을 확정시하면 microservice로 각잡고 개발하셨다는 경험을 들려주셔서 장단점이 존재함을 알 수 있었다. 한번쯤 DDD라는 단어를 스쳐본적이 있었는데 어려운용어가 아니고 협업하기 쉽도록 Domain을 간단하고 명료하게 이해하기 쉽게 가져단다는 것으로 이해하였다. 다음 포스팅은 Django의 기본 Setting과 동작원리와 관련된 포스팅을 할 예정이다.

 

 

 

 

 

Monolithic Architecture

• 장점

⇒ End-to-End 테스트가 용이

⇒ 빠르게 간단한 서비스를 만들 수 있음

 

• 단점

⇒ 조그마한 수정사항이 있어도 전체를 다시 빌드하고 배포

⇒ 유지보수도 힘듬

⇒ 덩치가 너무 커져 구동시간이 늘어남

⇒ 일부분의 오류가 전체에 영향을 미침

⇒ 각 기능에 따라 다른 언어를 선택할 수 없음

 

Microservice Architecture

: 거대한 서비스를 작은 서비스의 집합체로 보는 것

• 장점

⇒ 유지보수 용이

⇒ 거대한 서비스도 빠르게 수정 가능

⇒ 각 기능에 따라 다른 언어를 선택할 수 있음

• 단점

⇒ 모니터링이 힘듬

⇒ End-to-end 서비스 구동 불편(테스트가 불편)

 

 

 

기존 프로세스

기획자: 사업기획 / 서비스 기획 / 요구사항 정의

미케터: 사업 기획 / 지표 관리 / 아이디어 제안

개발자: 설계 / 구현 / 유지 보수

디자이너: 페이지 디자인 / 배너 디자인

PM: 조율 / 일정관리 / 감정받이..

 

• 기존 프로세스의 문제점

⇒ 소프트웨어 개발과 도메인, 모델과의 불일치 발생(도메인이 복잡하기 때문)

⇒ 기획과 개발의 불일치 발생

⇒ 소통 어려움

 

• 해결방안

   1.보변언어

⇒ 도메인에 대한 어휘를 이해관계자(기획자,개발자,분석가 등등)뜰이 공통적으로 이해할 수 있도록 정의

 

   2. 모델 주도 설계

⇒ 도메인 분석과 설계의 간극을 최소화

⇒ 분석/설계/구현의 모든 단계를 관통하는 하나의 모델을 유지

⇒ 모델 = 코드

 

 

DDD

• 도메인 주도 설계

⇒ 소프트웨어가 복잡한 이유는 도메인이 복잡하기 때문이다.

 

• 도메인이란?

⇒ 영역,집합

⇒ 비지니스 Domain을 의미

⇒ 예를 들어 주문,고객,주소관리 등등과 같이 분리

 

• 전략적 설계

⇒ 비지니스의 상황(Context: 대상자,상황)에 맞게 설계

⇒ 모든 Context를 이벤트 스토밍을 통해 공유

⇒ 각 Context를 그루핑(Bounded Context)

⇒ 컨텍스트 매핑을 통해 Bounded context간의 관계를 정의

 

• 전술적 설계

⇒ 더 상세한 부분(Bounded Context 내부)모델링

⇒ Model driven design

⇒ Aggregate Pattern

⇒ 계층형 아키텍처를 통한 도메인 모델 분리

⇒ 도메인 이벤트를 통해 도메인을 보다 명확히 모델링

 

 

정리하면 도메인을 전략적 설계로 모델화시키고 , 그 모델을 전술적 설계를 통해 소프트웨어로 만드는 것이 도메인 주도 설계(DDD)라고 할 수 있다.

 

 

https://bit.ly/3L3avNW

패스트캠퍼스 [직장인 실무교육]

*본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.