Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
Tags
- Java
- dfs
- docker
- Dynamic Routing
- zuul
- springcloud
- code refactoring
- container image #docker #layer #filesystem #content addressable
- BFS
- reactive
- test
- 단위테스트
- forkandjoinpool #threadpool #jvm #async #non-blocking
- Eureka
- spring cloud
- netflix
- api-gateway
- spring cloud netflix zuul
- unit
- 탐색
- spring cloud netflix
- Spring Data Redis
- netflix eureka
- java #jvm #reference #gc #strong reference
- 서비스스펙
- unittest
- 설계
- microservice architecture
- spring cloud netflix eureka
Archives
- Today
- Total
phantasmicmeans 기술 블로그
DDD Quickly - 1. 도메인 주도 설계란 무엇인가? 본문
자동화된 비즈니스 프로세스나 현실 세계의 문제가 소프트웨어의 도메인
이다.
소프트웨어는 도메인으로부터 시작되고 뗄 수 없는 관계를 가지고 있다.
좋은 소프트웨어를 만들기 위해서는, 그 소프트웨어가 무엇에 관련되어있는지를 알아야한다.
즉 도메인에 대한 깊은 지식이 필요하고, 우리가 출발해야 하는 곳은 언제나 도메인
이며 소프트웨어는 도메인을 모델링해야한다.
도메인 전문가와 이야기를 나누며 배운 여러 가공되지 않은 지식들을 기반으로 > 도메인을 추상화해야한다.
즉 추상화 > 도메인을 표현한 모델
모델
모델
== 대상 도메인에 대한 내부적 표현으로 설계와 개발 프로세스 내내 반드시 필요
- 하나의 도메인에는 모델로 만들기에는 정보가 너무 많기에 대부분은 고려할 필요조차 없다.
- 은행 소프트웨어는 고객의 주소를 반드시 관리해야하지만 눈 색깔은 알 필요가 없다.
우리는 모델
을 사용해서 도메인 전문가, 설계자, 개발자들과 의사소통해야한다.
도메인 지식 쌓기
- 비행 항로 제어 시스템을 예시로 듬
- 시스템의 시작은 도메인을 이해하는데서부터 출발
- 항공 도메인 전문가들과 소통
도메인 전문가들로부터 가능한 많은것을 배워야하고, 질문을 하고 올바른 방식으로 그것들을 가공해야한다.
이 정보들을 바탕으로 도메인 모델의 밑그림을 함께 그린다.
이 모델은 완전하지도 정답도 아니지만 꼭 필요한 출발점이다.
소프트웨어 전문가와 도메인 전문가들은 도메인 모델을 함께 만들어낸다. 이 과정은 시간을 소모하는 절차로 보일 수 있지만 꼭 그렇게 해야한다.
결국 소프트웨어의 목적이란 현실 세계의 도메인 안에 있는 비즈니스 문제들을 해결하기 위한 것이고, 따라서 도메인과 소프트웨어는 철저하게 혼합되어야 한다.
'DDD' 카테고리의 다른 글
DDD Quickly - 3. 모델 주도 설계 (0) | 2021.12.30 |
---|---|
DDD Quickly - 2. 유비쿼터스 언어 (0) | 2021.12.30 |
Comments