[도메인 주도 설계] 24.08.24/6주차 ~ 312p 유연한 설계 끝까지

[genie-youn]

[genie-youn]

https://docs.google.com/document/d/1Pmnun2qj0VDfugqNkqJHB4yo_KmJHITa5PsVZqirlsY/edit?usp=sharing

[hjsung809]

specification은 술어를 이용하여 도메인 로직을 간결하게 유지하라는 교훈을 주지만
따로 분리하기보다는 객체의 메서드로 만드는것이 현실적으로 유리할때가 많은것 같아요.

p258.

암시적인 개념을 찾아내서 이를 명확하게 표현했다면 일단 심층 모델을 만들 원재료는 갖춘 셈이다. 반복주기를 거쳐 핵심 관심사를 단순하고도 명확 하게 표현하는 모델을 계발하고, 클라이언트 개발자가 모델을 실제 작동 가능한 코드로 만들어 낼 수 있는 설계를 구성함으로써 이 재료를 유용한 형태로 만든다. 무수히 많은 과도한 엔지니어링이 유연성이라는 명목으로 정당화되어 왔다. 그러나 대개 너무 과도한 추상 계층과 간접 계층이 존재하면 오히려 유연성에 방해가 된다. 사용자에게 유용성을 제공하는 소프트웨어의 설계를 한번 살펴보기 바란댜 일반적으로 뭔가 단순한 것을 보게 될 것 이다. 단순하다는 것이 쉽다는 것을 의미하지는 않는다.

너무 좋은말 같아서 가져와봤습니다.

목표는 UBIQUITOUS LANGUAGE를 사용해 합리적으로 표현하기 위해 논리적으로 결합할 수 있고 관계없는 선택사항으로 인한 혼란과 유지보수의 부담이 없는 단순한 인터페이스 집합을 얻는 것이댜 이것은 일반적으로 리팩터링을 통해 달성할 수 있으며, 사전 설계로는 달성하기 어 렵다. 하지만 기술 지향적인 리팩터링으로는 결코 달성할 수 없을 것이댜 단순한 인터페이스 집 합은 심층적인 통찰력을 향한 리팩터링을 거쳐 드러난다

설계가 아닌 리팩토링으로 달성할수 있다는게 신기했어요

p280
리팩토링 후의 구조가 더 이해하기 어렵다는 생각이 들었어요. 더 표현력있고 책임이 잘나누어 있겠지만 객체지향, DDD는 결국 어려운 것. 쉬운게 아닌것 같아요. 어려운 문제를 쉽게 푸는게 객체지향이라는 생각이였는데 요즘은 어려운 문제를 쉽게 풀수는 없는것 같다는 생각 들어요

선언적 설계를 할때 그래프 큐엘을 활용할 수 있는것 같아요.
저희팀에 어떤분이 self 그래프 큐엘이라고 서버에서 읽기 모델을 만들기 보다는 그래프 큐엘로 선언적으로 자동으로 생성되는 모델을 사용할 수 있도록 적용했는데, 반복 작업이 없어지고 성능 최적화등의 문제도 한번에 해결하셨더라구요.
도메인 모델과 인테그레이션도 잘되구요. 잘쓰니까 정말 좋아보였어요