도메인 모델을 잘 정의하기 위해서 어떻게 해야할까요?

오브젝트 - 기초편

3-3. 표현적 차이 줄이기

해결된 질문

작성

안녕하세요. 좋은 강의를 통해 값진 지식을 얻어갔습니다. 감사합니다.

다름이 아니라 완강 이후 "좋은 도메인 모델은 어떻게 만드는 것인가?" 라는 의문이 들었습니다.

강의를 통해 도메인 모델과 변경의 관점에서 설계를 평가하는 방법과 책임을 부여하는 패턴들을 통해 개발자의 변경에 유연한 코드를 만드는 실마리는 얻었지만 한편으로는 이러한 부분들은 문맥을 제공하는 도메인 모델이 잘 정의되어있을 때, 빛이 발하는 것이 아닌가 생각이 들었습니다.

사실 현업에서 도메인 모델을 따로 정의하고 의식하면서 개발을 해본 경험이 없기 때문에 어떻게 하는 것이 좋을지 잘 모르겠습니다. 따라서 아래의 세부 의문점에 대해 답변해주실 수 있으면 감사하겠습니다.

도메인 모델은 개발 프로세스 중 어느 시점에 정의하는 것이 좋은지?
도메인 모델을 정의하는 것은 개발자가 주도적으로 이끄는 것인지 아니면 기획자와 같은 다른 팀원들과 함께 만들어 나가는 것인지?
만들어진 도메인 모델을 토대로 설계 및 개발을 진행하다 도메인 모델을 변경해야만 하는 순간이 있는지?
좋은 도메인 모델을 만들었는지 평가해볼만한 방법들이 있는지?

객체지향 소프트웨어-설계

답변 2

조영호

지식공유자

Binsk님 안녕하세요.

좋은 질문 해주셔서 감사합니다. 🙂

제가 아침부터 계속 강의를 하느라 이제서야 답글을 남기네요.

답변이 늦어져서 죄송합니다.

약간은 의아하게 들릴 수도 있겠지만 도메인 모델을 코드와 별개의 산출물로 보기 보다는 거의 같거나 또는 같은 내용을 서로 다른 형식으로 표현한 것 정도로 바라보는게 유용하다는 말씀을 드리고 싶어요.

강의에서 ‘표현적 차이’라는 개념을 설명드렸던 것처럼 코드의 구조를 통해 도메인 모델의 구조를 떠올릴 수 있도록 만드는게 좋습니다.

도메인 모델에 대한 이런 관점을 기반으로 하는 방식이 “도메인 주도 설계(Domain-Driven Design)"인데 관심이 있으시다면 한번 학습해 보시기를 권해드립니다.

이 관점을 중심으로 질문에 답변 드리도록 할게요.

Q: 도메인 모델은 개발 프로세스 중 어느 시점에 정의하는 것이 좋은지?

A: 어느 한 시점에 도메인 모델을 정의한다기 보다는 개발하는 기간 동안(또는 유지보수 기간 동안) 지속적으로 코드와 함께 도메인 모델을 정의하고 발전시켜 나가는게 좋습니다. 초반에는 도메인에 대한 지식이 명확하지 않고 요구사항이 계속 변경될 수 있기 때문에 소프트웨어의 생명주기 전반에 걸쳐 계속해서 도메인에 대한 관점을 변경하고 개선시키게 됩니다. 따라서 도메인 모델을 어느 한 시점에 정의한다기 보다는 소프트웨어가 종료될 때까지 계속해서 도메인 모델을 개선해야 한다고 생각하시면 좋습니다.

Q: 도메인 모델을 정의하는 것은 개발자가 주도적으로 이끄는 것인지 아니면 기획자와 같은 다른 팀원들과 함께 만들어 나가는 것인지?
A: 도메인 모델은 도메인에 대한 관점이기 때문에 코드뿐만 아니라 요구사항을 분석하고 커뮤니케이션할 때도 영향을 미치게 됩니다.
따라서 도메인 모델을 어떤 직군이 주도적으로 만들어 간다기 보다는 서로 협력하면서 같이 성장시켜 나가는 방식이 좋습니다.
다만 개발 직군 이외의 다른 직군분들이 이런 방식에 대해 가치가 있다고 생각하지 않거나 신경을 쓸 여유가 없으실 수도 있습니다.
이런 경우에는 개발자들이 주도적으로 논의를 이끌어가면서 도메인 모델을 정리하는게 효율적일 수 있습니다.
앞 답변에서 말씀드린 것처럼 이런 논의는 일회성으로 끝나면 안되고 지속적으로 이뤄지는게 좋습니다.

Q: 만들어진 도메인 모델을 토대로 설계 및 개발을 진행하다 도메인 모델을 변경해야만 하는 순간이 있는지?
A: 앞에서 말씀드린 것처럼 도메인 모델은 고정적인 것이 아니라 도메인에 대해 더 잘 알게 되거나 요구사항이 변경되서 도메인에 변화가 일어난다면 그에 맞게 도메인 모델도 변경되게 됩니다.

Q: 좋은 도메인 모델을 만들었는지 평가해볼만한 방법들이 있는지?
A: 코드가 도메인 모델을 반영하도록 만들었다고 가정할 때 요구사항이 변경되더라도 전체적인 코드의 구조가 크게 흔들리지 않는다면 좋은 도메인 모델을 만들었다고 볼 수 있습니다.
다시 말해서 도메인의 본질에 대한 관점이 코드 안에 안정적으로 정착됐다는 것을 의미합니다.

더 자세한 내용이 궁금하시다면 에릭 에반스가 쓴 “도메인 주도 설계(https://www.yes24.com/product/goods/5312881)"를 한 번 읽어보시기를 추천드립니다.

에릭 에반스는 책 전반에 걸쳐서 Binsk님이 궁금해하시는 부분에 대한 답을 체계적으로 정리해 놓았습니다.

(이후에 나온 대부분의 도메인 주도 설계 책들에는 이 관점이 누락되어 있는 경우가 많아서 읽기 힘드시더라도 에릭 에반스의 책을 보시는걸 추천드립니다.)

답변이 되었는지 모르겠네요. 🙂

행복한 주말 보내세요!

인프런 AI 인턴

안녕하세요, 인프런 AI 인턴입니다. Binsk님, 강의를 통해 많은 인사이트를 얻으셨다니 기쁩니다. 도메인 모델링은 소프트웨어 개발에서 매우 중요하면서도 복잡한 과제입니다. 이 주제에 대해 제가 답변 드리겠습니다.

도메인 모델의 정의 시점

초기 설계 단계: 도메인 모델은 프로젝트의 초기 단계에서 정의하는 것이 좋습니다. 이는 비즈니스 요구사항을 명확히 이해하고 프로젝트의 방향성을 설정하는 데 큰 도움이 됩니다. 도메인 모델은 변경이 가능한 문서로, 프로젝트 초기에는 이를 통해 비즈니스 요구사항을 구체화하고 이해하는 데 초점을 맞춥니다.

도메인 모델의 정의 과정

협업을 통한 정의: 도메인 모델은 개발자뿐만 아니라 기획자, 비즈니스 전문가 등 다양한 이해관계자들과 협력하여 정의하는 것이 좋습니다. 이는 비즈니스 도메인에 대한 다양한 관점을 반영하여 더 의미 있는 모델을 만들 수 있습니다. 따라서 도메인 지식이 중요한 팀원과 함께 정의해야 합니다.

도메인 모델의 변경 가능성

변경의 유연성: 도메인 모델은 프로젝트가 진행되면서 새로운 요구사항이나 변경된 비즈니스 규칙에 따라 수정될 수 있습니다. 그래서 초기 설계 시에 유연성과 적응성을 고려하여 설계하는 것이 중요합니다. 실제 개발 과정에서 도메인 모델을 지속적으로 검토하고 필요에 따라 변경하는 프로세스를 마련해야 합니다.

좋은 도메인 모델을 평가하는 방법

평가 기준: 좋은 도메인 모델을 만들었는지 평가하기 위해 몇 가지 기준을 사용할 수 있습니다:
- 비즈니스 요구사항과 일치하는가: 모델이 비즈니스 요구사항을 정확하게 반영하고 있는지 확인합니다.
- 유연성과 확장성: 모델이 변경과 확장을 수용할 수 있도록 설계되었는지 평가합니다.
- 명확성과 이해도: 이해관계자들이 모델을 쉽게 이해하고 사용할 수 있는지, 명확한지 평가합니다.

유사한 내용을 다룬 질문과 답변을 참고하시면 추가적인 인사이트를 얻을 수 있습니다:
- 설계 방법론에 관한 질문드립니다.
- 객체지향 설계 관련하여 궁금한것이 있습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

인프런 커뮤니티 질문&답변