파이썬으로 살펴보는 아키텍처 패턴 - 1장

첫 번째 파트(도메인 모델링을 지원하는 아키텍처 구축)의 첫 번째 장은 '도메인 모델링'에 대한 내용이다.

대부분의 개발자는 자신의 시스템 아키텍처가 더 나아질 수 있다는 느낌을 계속 받기에
잘못된 시스템을 구하려고 시도하거나 질서를 다시 불어넣기 위해 노력하고는 한다.
자신의 비즈니스 로직이 여러 곳에 퍼지면 안 된다는 사실을 알고는 있지만 이를 고치는 방법에 대해서는 전혀 모른다.

대부분의 개발자가 시스템을 새로 설계하라는 요청을 받으면
DB 스키마를 그리기 시작한 뒤 객체 모델을 생성하다. 여기서부터 모든 것이 잘못된다.
그 대신 먼저 행동하고 저장에 대한 요구 사항은 행동에 맞춰 정해져야 한다.
무엇보다 고객은 데이터 모델에 대해 신경 쓰지 않으며 그냥 어떤 일을 하는지에 대해서만 신경 쓴다.

첫 번째 파트에서는 아래의 4가지 핵심 설계 패턴을 소개한다.
저장소 패턴 : 영속적인 저장소에 대한 추상화
서비스 계층 패턴 : 유스 케이스의 시작과 끝을 명확하게 정의하기 위한 패턴
작업 단위 패턴 : 원자적 연산을 제공
애그리게이트 패턴 : 데이터 정합성을 강화하기 위한 패턴

첫 번째 장부터는 예제 소스가 꽤 많이 나온다.
모든 소스들을 블로그에 첨부하는 건 딱히 의미가 없는 것으로 보여서 어떻게 해야 할지 고민이다.
이번 장은 1.1-2, 1.3-4 두 부분으로 나눠서 진행을 해야 할 것 같다.

1.1 도메인 모델이란?
- 이제부터 비즈니스 로직 계층 대신 도메인 모델이라는 용어로 사용.
- 도메인 : 해결하려는 문제. 프로세스가 지원하는 활동을 의미
- 모델 : 유용한 특성을 포함하는 프로세스나 현상의 지도(map)를 의미. 
- 도메인 모델 : 비즈니스를 수행하는 사람이 자신의 비즈니스에 대해 마음속에 가지고 있는 지도와 같음. 복잡한 시스템을 다루기 위해 협력하는 사람들 사이에 그들만의 용어가 생기는 건 자연스러운 현상.
- DDD : 소프트웨어에서 가장 중요한 요소는 문제에 대해 유용한 모델을 제공하는 것. 모델을 잘못 만들면, 잘못된 모델을 우회해야 하기 때문에 모델이 장애물이 됨. 

1.2 도메인 언어 탐구
- 도메인 모델을 이해하려면 시간과 인내가 많이 필요.
- 처음에는 비즈니스 전문가들과 대화를 통해 최초로 만들 최소한의 도메인 모델에 사용할 용어와 규칙을 몇 개 정해야 함.
- 가능한 한 각 규칙을 잘 보여주는 구체적인 예제를 요청하는 것이 좋음.
- 규칙을 비즈니스 전문용어(DDD에서는 유비쿼터스 언어)로 표현해야 함. 사용할 개체를 기억하기 쉬운 이름(식별자)을 부여해 대화할 때 대상을 쉽게 공유할 수 있게 함.

저자가 소개할 도메인 모델은 '가구 판매 회사'의 도메인 모델이다.
현업과는 조금 차이가 있을지 모르겠지만
에센셜한 예제를 잘 익혀주면 내 분야에도 써먹을 수 있을 테니 편견을 갖지 말고 공부해보자!