23_12_18 Kotlin

DDD 란 
domain driven design
비즈니스 요구사항을 기반으로 소프트웨어를 설계하는것

전략적 설계(Strategic Design): 개념에 대헤 정의하고 설계하는데 중점을 둠
각 context를 분리하여 독립적으로 설계함 
소프트웨서의 요구사항을 명확하게 정의 개념적인 설계 

전술적 설계(Tactical Design): 각 영역의 도메인을 모델로 만들고 수현하는 방법에 중점 
애플리케이션의 구체적인 설계과정

Ubiquitous Language :  공통된 언어(단어) 를 통해 개발을 하자 

Actor: 도메인에 속해있는 사용자 (유저) 소개팅 어플 이라면 남자와 여자(유저) 어드민 (관리자)

Domain Event : 도메인에서 발생하는 사건들 과거시제로 기록함(로그인에 성공함 / 상품이 배송됨)

Commeand : 도메인 이벤트를 유발시키는명령 보통 api로 대응됨

policy : 도메인내에 규칙 정책 도메인 이벤트뒤에 따라오는 하나의 비즈니스 로직

폴리시에 의해 다른 이벤트가 트리거가 될수있다  매월 카드결제일이 되면( 규칙) 계좌에서 결제대금이 빠져나감(Event)

External System: 우리가 짜는 서비스가 아닌 외부의  별도 시스템 이메일 전송 시스템 결제시스템 같은 외부 시스템 외부 시스템에 의대 이벤트가 트리거 되기도함

hotspot: 의문 혹은 질문 미결정 사항 비즈니스 요구사항을 미결정했을때?

aggregate: 비즈니스 로직수행을 위한 데이터 객체의 집합 
주문이라는 개념은 배송정보 배송지 결제정보 등등이 포함되어있음 
도메인마다 성격이 다르고 정의하기 어려움 모델간의 경계를 잘 정의할수있고 코드의 일관성을 유지할수있다
도메인이 복잡할때 힘을 발휘함

bounded context :액터 도메인이벤트 커맨드를 고려한 하나의 집합 
쇼핑몰의 예로는 회원가입 정보수정을 담당하는 회원콘텍스트 
상품의 주문 및 결제를 담당하는 상품 콘텍스트 
배송을 담당하는 배송 콘텍스트 

 

필기한거 머리에 때려 박는다고 강의 별로 못들어서 오늘은 많이 못배웠지만 열정적인 팀원들이 서버통신에 대한 특강? 같은거도 해주고 내가 알고있는 개념을 발표하는 시간을 가져서 또 다른 지식을 습득했다 ! 항상 팀편성할때 멘토 같은분이 계서서 너무 다행이다 럭키가이 오늘도 고생했다 !