일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- AWSKRUG
- serverless
- 머신러닝
- 도메인 주도 설계
- Zappa
- zookeeper
- Leetcode
- LAMBDA
- React
- 회고
- 아키텍처
- billing
- 하이트진로
- HEXO
- 알고리즘
- 메세지큐
- Notion
- ddd
- finops
- 노션
- amqp
- 백준
- API Gateway
- 2020년
- 맥주
- S3
- github pages
- AWS
- Kafka
- CloudWatch
- Today
- Total
목록아키텍쳐/도메인 주도 설계 (2)
인생은 고통의 연속
아키텍처 설계시 필요한 영역 표현(UI) 영역 : 사용자의 요청을 받아 응용 영역에 전달하거나 응용 영역의 처리 결과를 사용자에게 보여줌. 대표적으로 스프링 MVC 프레임워크가 해당함. 응용 영역 : 도메인 모델을 이용해서 사용자에게 제공할 기능을 구현. 실제 도메인 로직 구현은 도메인 모델에 위임한다. 도메인 영역 : 도메인 모델을 구현. 도메인 모델은 도메인의 핵심 로직을 구현. 인프라스트럭처 영역 : 논리적인 개념을 표현하기보다는 실제 구현 기술에 대한 것을 다룬다. ※ 표현/도메인/응용 영역은 구현 기술을 사용한 코드를 직접 만들지 않는다. 대신 인프라 스트럭처 영역에서 제공하는 기능을 사용해서 필요한 기능을 개발한다. (응용 영역에서 DB의 쿼리를 직접 사용하거나 도메인 영역에서 메일을 보내기 ..
기존의 설계 방식 컨트롤러-서비스-DAO-DTO (전형적인 Spring API 구조) 도메인 도메인 : 문제 해결하고자 하는 문제 영역. 도메인은 여러 하위 도메인으로 구성한다. SW는 도메인의 모든 기능을 제공하지 않는다.(예를 들어 결제는 외부 시스템(PG)을 사용하는 것처럼) 도메인 모델 도메인 모델 : 특정 도메인을 개념적으로 표현. 도메인 자체를 이해하기 위한 개념 모델. 기능과 데이터를 함께 보여주는 객체 모델은 도메인을 모델링하기 적합함. 하지만 도메인 모델은 객체로만 모델링하지 않는다. 즉, 클래스/상태 다이어그램과 같은 UML(Unified Modeling Language) 표기법만 사용해야 하는건 아님. 관계가 중요한 도메인이라면 그래프를 이용해서 도메인을 모델링. 계산 규칙이 중요하다..