caffeine-library / Domain-Driven-Design

🌱 에릭 에반스의 '도메인 주도 설계'를 읽는 스터디
4 stars 0 forks source link

[question] 선언적 설계에서의 패키지화 #27

Closed kth990303 closed 1 year ago

kth990303 commented 1 year ago

질문

p.119 에 아래와 같은 문구가 나옵니다.

패키지화를 바탕으로 다른 코드로부터 도메인 계층을 분리하라. 그렇게 할 수 없다면 가능한 한 도메인 개발자가 자신의 모델과 설계 의사과정을 지원하는 형태로 도메인 객체를 자유로이 패키지화할 수 있게 하라.

저는 해당 문구를 높은 응집도/낮은 결합도를 기준으로 각 도메인을 모듈화(패키지화)하여 책임 및 관심사를 분리하여, 특정 도메인 개발자가 자신의 도메인에만 신경쓸 수 있도록 해야 한다고 이해했습니다. 패키지화(모듈화)의 장점에 대해 얘기한 문구라고 생각한 것이죠.

의문이 든 부분

그런데 아래 문구를 보고 의문이 들었습니다. 아니, 사실 이해가 아예 안된다고 하는 게 맞겠네요.

한 가지 예외적인 경우는 선언적 설계(10장에서 논의하겠다)를 기반으로 코드가 만들어질 때다. 이 경우 개발자들은 코드를 읽을 필요가 없으므로 생성되는 코드를 가까이에 있지 않게 별도의 패키지에 집어넣어 개발자가 실제로 작업해야 할 설계 요소를 어지럽히지 않는 게 좋다.

선언적 설계는 저번 시간에 얘기를 나눴듯이, 세부 로직은 캡슐화하고 결과를 반환하는 형태라고 (대략적으로) 알고 있습니다. 따라서 개발자들은 코드를 읽을 필요가 없다는 것은 이해가 됩니다.

그런데 이해가 되지 않는 부분은 한 가지 예외적인 경우 문구입니다. 패키지화(모듈화) 역시 타 모듈에 대한 코드를 읽지 않기 위해 별도의 모듈로 분리하는 것인데 왜 선언적 설계는 예외적인 경우라고 말하는 것일까? 하는 생각이 들었습니다.

선언적 설계에 대해 잘 몰라서 그런 것일수도 있다고 생각합니다. 왜 책에서는 이렇게 말한건지 잘 모르겠습니다.. 어렵네요 흑흑

연관 챕터

24

leejaeseung commented 1 year ago

책이 아무래도 번역본이라 매끄럽지 않아 이해하기가 쉽지 않군요..ㅜㅜ 정확하진 않지만 제가 이해한 내용을 한번 정리해 봅니다.

선언적이지 않은 설계 라면 패지키/모듈을 분리하더라도 가까운 경계 내에서 분리하고, 선언적 설계 라면 아예 별개의 패키지/모듈로 분리하는게 가능하다 라는 내용으로 이해했습니다.

제가 생각하는 선언적이지 않은 코드선언적인 코드를 예시로 들어보면, 선언적이지 않은 코드

validateDay(day) // 날짜를 검증하는 로직입니다.

위 코드도 검증 로직과 다른 로직을 분리하는 작업은 필요하겠지만, validateDay 만 보고는 어떤 로직인지 알 수 없고 실제 코드를 봐야 알 수 있겠죠. (즉, 패키지/모듈 간의 의존성이 존재합니다.) 선언적인 코드

day
.filter(isBeforeToday)
.filter(isNotMinus)

위 코드는 day 를 각 람다 함수로 필터링하는 로직입니다. isBeforeTodayisNotMinus 같은 함수는 아예 별개의 패키지/모듈에 독립적으로 존재할 수 잇겠죠.(의존성이 존재하지 않습니다. 각 함수들의 연산이 명확하고, 일반적이니..)

요약하자면, 의존성을 분리한다 vs 의존성을 완전히 끊어버린다 의 차이라고 생각하였습니다.

10 장 p.283 의 독립형 클래스 에서 각 클래스의 의존성을 최대한 없애는 걸 설명하는데(극단적이라면 zero) 이와 비슷한 내용인 듯 합니다!

kth990303 commented 1 year ago

선언적 코드란 무엇일까? 어떻게 보면 검증을 의미한다고 명확히 해석이 되는 validateDay(day)가 좀 더 선언적인 코드가 될 수 있지 않을까 vs 무엇을 검증하는지 명확하게 드러내주는day.filter(isBeforeToday)...와 같이 그 코드만 보고 내용을 바로 이해할 수 있는 코드가 좀 더 선언적인 코드가 될 수 있지 않을까