search

caffeine-library / Domain-Driven-Design

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

[question] 도메인 주도 개발의 의의 #3

Closed wooyounggggg closed 1 year ago

wooyounggggg commented 1 year ago

질문

Spring 스터디 초창기에, 아래의 토론에서 스프링의 근본이 무엇인지 탐구하는 과정을 통해 스프링이 어떤 철학을 가지고 생겨났는지, 스프링의 등장이 어떤 의의를 가지는지 등 더 넓은 맥락에서 스프링을 이해할 수 있었고, 지금도 그 관점을 이해한 것이 도움이 많이 되는 것 같습니다.

마찬가지로 도메인 주도 개발의 등장 또한 개발의 패러다임을 바꾼 사건이라고 생각하지만, 정확히 어떤 측면에서 유의미한 변화를 가져왔는지 정리해본 적은 없는 것 같습니다.

스터디를 통해 개념을 정리하고, 생각을 공유한다면 앞으로의 DDD 스터디에 뚜렷한 방향성을 확립할 수 있을 것 같습니다.

Q) DDD가 등장하기 전후로 무엇이 바뀌었고, 어떤 의의가 있다고 생각하시나요?

Q) DDD를 관통하는 철학은 무엇이라고 생각하시는지 궁금합니다.(DDD를 한 문장으로 표현한다면?)

연관 챕터

1

JasonYoo1995 commented 1 year ago

Q) DDD가 등장하기 전후로 무엇이 바뀌었고, 어떤 의의가 있다고 생각하시나요?

Q) DDD를 관통하는 철학은 무엇이라고 생각하시는지 궁금합니다.

leejaeseung commented 1 year ago

Q) DDD가 등장하기 전후로 무엇이 바뀌었고, 어떤 의의가 있다고 생각하시나요?

DDD 를 배우면서 느낀 점은 "정답은 없다" 였습니다. DDD 에선 도메인 위주로 설계하자! 말고는 어떤 패턴을 적용해야 한다거나, 어떤 아키텍쳐를 적용해야 한다 라는 규칙이 전혀 없습니다. 항상 도메인에 맞춰 유연하게 설계해야 합니다.

최근에 팀에서도 DDD 적으로 개발을 해보고 있는데, 이전에 작성되어 있던 코드는 무언가 틀에 갇혀있다는 생각이 들었습니다.

단순한 예로 파일구조를 들 수 있는데, controller service 와 같이 미리 파일들을 만들어두고 구현하는 고전적인 방식을 사용했습니다. 기능을 추가할 때도 도메인(비즈니스)적인 관점에서 생각하기보단 기존에 있는 틀로 코드를 만들고 기능을 추가하는 느낌이었습니다. (틀을 맞추기 위한 코드가 불필요하게 추가될수도 있겠죠)

최근들어 DDD 적으로 개발하고부턴 money(도메인) 라는 디렉토리만 만들고 시작합니다. 내부는 자유롭게 구성할 수 있겠죠. 레이어드 아키텍쳐를 사용해도 되고, 헥사고날을 적용해도 됩니다.

DDD 의 의의는 도메인이라는 정말 큰 틀 하나만을 정해두고 자유롭고 유연하게 개발/설계하는 것이라고 생각합니다.

Q) DDD를 관통하는 철학은 무엇이라고 생각하시는지 궁금합니다.

"정답은 없다." 인 것 같습니다. DDD 는 문제 해결법을 알려줄 뿐, 어떤게 가장 좋다 라고 절대 말하지 않습니다.

wooyounggggg commented 1 year ago

남겨주신 comment들을 확인하고, 저도 생각을 정리하게 되었습니다.

6 이슈와도 연관이 깊어 보이네요.

이슈를 다루기 전에, 책 p.4의 내용을 다시 살펴보았습니다.

소프트웨어의 본질은 해당 소프트웨어의 사용자를 위해 도메인에 관련된 문제를 해결하는 능력에 있다. 그 밖의 매우 중요하다 할 수 있는 기능도 모두 이러한 기본적인 목적을 뒷받침하는 데 불과하다.

에릭 에반스의 말처럼, 소프트웨어의 중심은 도메인에 있다고 생각합니다. 그렇기에, 코드베이스의 핵심 자산 또한 도메인을 표현하는 코드라고 생각합니다. 그러나 DDD의 등장 이전에는 도메인이라는 개념이 지금보다 상대적으로 약하지 않았을까?라는 추측을 하게 되었습니다.

왜 그렇게 생각했는지 아래의 질문을 정리하면서, 이어서 이야기 하겠습니다.

Q) DDD가 등장하기 전후로 무엇이 바뀌었고, 어떤 의의가 있다고 생각하시나요?

관점의 변화(기술 -> 도메인)

저는 DDD를 공부하면서, 프로젝트를 바라보는 관점이 기술 -> 도메인 중심으로 옮겨가게 된 것이 DDD의 핵심이자 의의라고 생각합니다. Layered Architecture에서는 Service Layer의 어딘가에 도메인 로직들이 흩어져 있고, 비즈니스 로직은 서비스 클래스에 위치한다라는 원칙만 존재했을 뿐, 우리가 가장 많이 다뤄야 하는 비즈니스 도메인을 표현하는 개념이 존재하지 않았습니다.

그 결과, 실제로 비즈니스에서 일어나는 일을 코드와 모델에 나타내는 과정에 괴리가 있었고, 이러한 간극이 시간이 지날수록 커지면서 치르는 비용도 증가한 것으로 생각됩니다.

DDD가 등장하면서 개발자들은 서비스 로직에 파묻혀있던 도메인이라는 개념을 분리해낼 수 있었고, 좀 더 응집성 있게 다루어야 하는 대상이 무엇인지 구별할 수 있었던 것 같습니다.

Q) DDD를 관통하는 철학은 무엇이라고 생각하시는지 궁금합니다. 기술을 걷어낸, 순수한 도메인 중심 사고인 것 같습니다.

소프트웨어를 구성하는 것은 크게 아래의 두 분류가 있다고 생각합니다.

저는 위 두 항목 중, 첫 번째인 도메인 로직을 항상 먼저, 중심적으로 사고하는 것이, 에릭 에반스가 DDD를 통해 하고싶었던 말이 아닐까 생각합니다.

2023.01.14

좀 더 생각해보니, 위의 의견은 소프트웨어 구현 관점에 치우쳐 DDD의 의미를 해석한 것 같기도 합니다. 소프트웨어 기술자의 관점에서는 위의 생각은 어느정도 맞는 것으로 보이지만, 프로젝트 참여자의 관점에서 봤을 때는 도메인 이해 관계자들을 하나의 바운더리에 묶어두어서 의사 소통 효율을 극대화하고 정말 중요한 도메인에 집중할 수 있게 하는 방법론 정도로 해석이 되는 것 같네요