인프런 커뮤니티 질문&답변
작성한 질문수
실제로 객체지향으로 설계를 많이 하는지 궁금합니다.
해결된 질문
작성
·
1.3K
4
먼저, 강의 너무 잘 들었습니다. 너무 좋은 내용을 압축적으로 전달 받았습니다. 감사합니다.
강의를 듣고 나니, 두 가지가 인상깊었는데요.
객체를 사용한다고 해서 객체 지향이 아니구나. 객체를 사용하더라도 절차지향적으로 설계할 수 있다.
객체지향 설계를 제대로 하다보면, DDD를 자연스레 실천하게 된다. (DDD 패턴을 적용하는 것은 아님)
실제 사용 중인 코드를 보니, Service 객체가 비즈니스 로직을 왕창 들고 있더라구요. 클래스의 인스턴스도 객체보다는 데이터에 가까웠습니다. 데이터만 담고 있고, 데이터를 조작하는 로직은 모두 Service가 들고 있었어요. "그동안 절차지향적으로 코드를 작성했던거구나!"를 알게 되었습니다.
그러면서 문득, 강사님 블로그에서 봤던 글이 생각났는데요. [도메인 주도 설계의 본질](https://eternity-object.tistory.com/26)이라는 글의 마지막 부분입니다.
아마 모든 소프트웨어 애플리케이션의 95%는 “DDD를 적용하기에 적절하지 않은” 범주에 속할 것이다. 대부분의 소프트웨어는 근본적으로 데이터 중심적이다.
여기서 말씀하시는 "데이터 중심적"이라는 것이, 데이터를 먼저 설계하고 프로세스를 나중에 설계하는 절차지향적 설계를 말씀하신 것인지가 궁금했습니다. 제가 이해한 바가 맞을까요?
적고보니 질문을 위한 사족(?)이 길었군요. 답변 주시면 감사하겠습니다 :)
답변 2
2
High-East님 안녕하세요.
먼저 강의 들어주셔서 감사하다는 말씀 먼저 드립니다. 🙂
강의가 도움이 되었다니 다행이네요.
저도 예전에 "그동안 절차적으로 코드를 작성했던 거구나!"라는 깨달음을 얻는 순간부터 설계와 유지보수에 대한 관점이 많이 바뀌고 많은 부분에서 성장했었어요.
질문하신 내용 중에서 DDD와 객체지향 사이의 관계에 관해 간단히 설명드린 후에 질문하신 내용에 대해 답변 드리도록 하겠습니다.
DDD는 복잡한 도메인의 문제를 해결하기 위해 적용할 수 있는 사고 방식과 우선 순위의 모음입니다. DDD는 단순히 코드를 설계하는 방법을 넘어서서 도메인 분석, 리팩토링, 시스템 분할, 협업 방식, 조직 구조를 아우르는 거대한 패턴 언어를 의미합니다.
반면에 객체지향은 유지보수 가능한 소프트웨어를 만들기 위해 변경하기 쉽도록 코드를 배치하는 방법을 가이드하는 것이 목적입니다. 도메인라는 넓은 범위의 문제를 다루는 DDD와 달리 객체지향은 코드라는 좁은 범위의 문제를 다룬다는 점에서 차이가 크다고 할 수 잇습니다.
결과적으로 DDD를 하기 위해 반드시 객체지향이 필요한 것은 아니고, 객체지향을 한다고 해서 반드시 DDD를 해야하는 것은 아닙니다.
DDD가 객체지향 커뮤니티의 영향을 받았기 때문에 객체지향 개념에서 많은 부분을 차용했기 때문에 강의에서 다루는 내용이 개념적으로 DDD와 겹치는 부분이 있기는 하지만 명확하게 말하면 강의에서 다루는 내용을 DDD라고 부르기에는 조금 애매하다는 점을 먼저 말씀드릴게요.
비슷한 질문을 많이 받다보니 "도메인 주도 설계의 사실과 오해(https://edu.nextstep.camp/c/SXgXIKdd/)"라는 오프라인 강의를 통해 혼란스러운 부분을 정리해드리고 있습니다.
이렇게 장황하게 설명드린 이유는 질문 주셨던 아티클에서 인용한 "DDD를 적용하기에 적절하지 않은"이라는 문구가 "객체지향을 적용하기에 적절하지 않은"이라는 의미가 아니라는 말씀을 드리고 싶어서에요.
앞에서 설명드린 것처럼 DDD와 객체지향은 독립적인 개념이기 때문에 DDD를 적용하기에 적절하지 않은 문제라고 하더라도 객체지향을 이용해서 해결할 수 있습니다.
블로그 글(https://eternity-object.tistory.com/26)에서 인용한 아티클에서 이야기하고 있는 데이터 중심적이라는 이야기는 도메인의 복잡도라고 생각하시면 될것 같습니다.
인용글에서 언급한 것처럼 "매우 복잡하고 잘 정의된 비즈니스 모델에 초점을 맞추어야 하는 소프트웨어"가 아니라면, 즉 도메인의 복잡도가 높지 않다면 DDD에서 말하는 유비쿼터스 랭귀지나 도메인 모델, 바운디드 컨텍스트의 개념이 오히려 방해가 되기 때문에 DDD는 적합하지 않을 수 있습니다.
어떤 도메인은 순수하게 데이터를 처리하는 것을 목적으로 할 수도 있습니다.
이런 경우 DDD를 적용하지 않는 것이 더 좋겠죠.
다만 도메인이 데이터 중심이라고 하더라도 일부 코든 객체지향적인 방식으로 구현하고 일부 코드는 절차적인 방식으로 구현할 수 있습니다.
요약하면 "데이터 중심"이라는 말은 도메인의 특성을 의미하는 것이며 코드의 배치가 "절차적인 방식"이라는 것과는 무관하다고 말씀 드릴 수 있겠습니다.
블로그의 마지막 부분에 해당 아티클을 인용한 이유는 DDD가 모든 문제를 해결해주지 않으며 DDD는 목적이 아니라 수단이기 때문에 적용 여부를 신중하게 선택했으면 하는 마음에서 였습니다.
제가 저 글을 썼던 2009년에 비해(벌써 15년이나 흘렀네요) 현재는 DDD를 적용하기에 적합한 영역이 많이 늘어났지만 여전히 DDD의 적용 여부를 보수적으로 판단해애 한다는 사실은 변하지 않은 것 같습니다.
길이 길어졌는데 혹시 더 궁금한 부분 있으시면 댓글 부탁드립니다. 🙂
감사합니다!
1)~4)까지는 데이터 중심의 도메인의 간단한 예이고, 5) ~ 6)은 개발 조직의 상황에 따라 적용 여부를 고민하면 좋은 경우입니다. 🙂
1) 단순한 CRUD 중심의 도메인
이 구분은 도메인의 복잡도와 관련이 있습니다.
UI/또는 다른 시스템에서 전송된 데이터를 복잡한 처리 없이 데이터베이스로 저장하고 저장된 데이터를 화면에 조회하는 애플리케이션
이 경우 저장/수정 연산의 경우 전달된 데이터를 복잡한 가공없이 그대로 데이터베이스로 전달하고, 조회 연산의 경우 데이터를 읽어와 DTO로 매핑하는 일이 주된 작업입니다.
이 경우 동일한 도메인이라고 하더라도 복잡도에 따라 CRUD 중심이냐 아니냐가 나눠지는데 글을 저장하고 수정하는데 초점이 맞춰진 간단한 커뮤니티 시스템은 CRUD 중심의 애플리케이션으로 구현 가능하지만 네이버나 다음의 카페는 생각보다 내부 로직이 도메인이 복잡하기 때문에 DDD로 구현하는게 적합합니다.
도메인 로직이 복잡하지 않을 경우에 DDD의 프랙티스를 사용하면 득보다 실이 많습니다.
2) 데이터 변환 중심의 도메인
데이터를 대용량 로그를 수집하고 처리하거나 다른 데이터베이스를 연동해서 검색의 색인을 만드는 과정은 원본 데이터를 타겟 데이터로 변환하는데 초점이 맞춰져 있습니다. 이 경우 본질적으로 하나의 데이터 포맷을 다른 데이터 포맷으로 변환하는 것이 핵심이기 때문에 도메인 모델 중심의 DDD를 적용하는게 특별한 메리트가 없습니다. 빅데이터 분석, 데이터웨어하우징, ETL과 같은 데이터 조직의 업무에는 DDD를 적용하기가 어려운 경우가 많습니다.
3) 상품 목록 조회와 같은 퍼포먼스 향상이 목적인 도메인
대부분의 이커머스에서 상품 목록은 별도의 시스템으로 구축하고 상품 데이터를 출력하기 편한 방식으로 재가공해서 별도의 영속성 저장소에 저장해 놓습니다. 이처럼 조회를 위해 별도의 시스템을 구축하는(CQRS를 적용하는 경우라고 보셔도 됩니다) 경우에는 데이터 중심의 애플리케이션을 구축하게 됩니다.
4) 마케팅과 같이 매번 변경되는 도메인
마케팅을 위해 애드혹하게 만들어지는 프로모션 페이지의 경우에는 데이터 중심으로 만들어지는 경우가 많습니다. 이벤트가 끝나면 폐기되는 기능을 위해 DDD를 적용할 경우 리소스 대비 얻는게 적기 때문입니다.
5) 빠르게 결과를 확인하기 위해 만드는 시스템
비슷하게 프로토타이핑 용도로 빠르게 출시하고 시장의 반응을 보고 싶을 경우에도 DDD를 적용하면 좋지 않은 경우가 많은데 일반적으로 DDD는 초기에 리소스를 많이 투자해야 하기 때문입니다.
6) 인력이 적을 경우
제 개인적으로 시스템을 구현하는 인력이 3~4명 정도라면 DDD를 적용하지 않는게 좋다고 생각하는 편입니다. 경우에 따라 다르겠지만 인력이 적은 경우 대부분 도메인의 복잡도가 낮은 경우가 많고 도메인 모델이나 DDD의 복잡한 프랙티스를 따르지 않더라도 시스템을 관리할 수 있는 경우가 많기 때문입니다. 부분적으로 엔티티, 값 객체, 애그리거트와 같은 패턴을 따르는 정도는 무방하겠지만 인원이 적은 경우에는 해당 패턴을 적용해서 얻는 이익이 생각보다 많지는 않습니다.
답변이 되었는지 모르겠네요. 🙂
대부분의 소프트웨어는 근본적으로 데이터 중심적이다.
위 문장을 "데이터가 중심인 도메인과 아닌 도메인이 있는 것인가?"라고 생각했었는데, 그게 아니라 "데이터 중심적으로 처리해도 충분한 경우와(혹은 처리해야 하는 경우와), 비즈니스가 복잡해서 도메인 중심으로 처리하면 효과적인 경우"가 있는 것으로 보는게 맞겠군요 :)
도움이 많이 되었습니다. 감사합니다. 준비 중이신 강의도 기대하겠습니다!!
기회가 된다면 오프라인에서도 찾아뵐게요 :)
제가 설명드리고 싶은 부분을 저보다 더 깔끔하게 정리해 주셨네요. 🙂
도움이 되셨다니 정말 다행입니다.
다음 강의도 잘 준비해 볼게요!
오프라인에서 뵐 때 이 질문 다시 한번 말씀해 주시면 좀 더 이해하시기 쉽게 설명 드리도록 하겠습니다.
주말 잘 마무리 하세요!
0
안녕하세요, 인프런 AI 인턴입니다.
High-East님 질문하신 내용에 대해 조영호 강사님께서 작성하신 “도메인 주도 설계의 본질“이라는 글은 실제로 객체지향 설계와 데이터 중심의 설계 방식에 대한 차이 및 DDD의 적용 적절성에 대해 설명하고 있습니다.
이 글에서 조영호 강사님은 대부분의 소프트웨어가 데이터 중심적이라고 언급하시며, 이것이 객체지향적인 설계와는 다른점을 지적하셨습니다. 데이터 중심적 설계는 데이터(즉, 필요한 정보의 구조)를 먼저 고려하고, 그 주위에 로직(함수, 메서드)를 배치하는 방식이라 할 수 있습니다. 이는 데이터를 중심으로 시스템이 구성되며, 때론 이러한 구조가 절차지향적인 패턴으로 이어질 수 있다는 것을 의미합니다.
반면, 객체지향 설계는 데이터와 그 데이터를 처리하는 메소드를 함께 묶어서 객체를 만들고, 이 객체들이 상호작용함으로써 프로그램이 구성되는 방식입니다. 각 객체는 특정 역할(Role), 책임(Responsibility), 협력(Collaboration)을 가집니다.
High-East님이 관찰하신 “Service 객체가 비즈니스 로직을 왕창 들고 있는” 상황은 실제로 많은 프로젝트에서 흔히 볼 수 있는 형태로, 이는 절차지향적인 설계의 반영일 수 있습니다. 객체지향 설계원칙을 제대로 적용하려면, 데이터와 행위를 함께 갖고 있는 객체에 비즈니스 로직을 적절히 분배하여 해당 객체의 책임과 역할에 맞게 설계해야 합니다.
따라서 High-East님이 이해하신 바와 같이, “데이터 중심적” 설계가 절차지향적인 설계의 특징을 반영하는 것으로 보시는 것이 맞습니다. 객체지향적 설계 방식에서는 데이터뿐만 아니라, 데이터를 어떻게 사용할 것인지, 데이터와 데이터가 상호작용하는 방식 등을 함께 고려하여 전체 시스템을 구성하게 됩니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
먼저, 상세한 답변 너무 감사합니다!
객체지향적인 설계와 DDD는 독립적인 개념이다.
"데이터 중심"이 "절차적인 방식"과는 무관하다.
도메인이 "데이터 중심인지"의 여부에 따라, DDD를 적용하는게 좋을 수도 아닐 수도 있다.
로 정리가 되었습니다.
추가로, "데이터가 중심인 도메인"과 "데이터가 중심이 아닌 도메인"에 대해 고민해보았는데, 명확한 기준을 잘 모르겠습니다. 관점에 따라 달라질 수도 있는 것인가 싶기도 하구요.
그래서, "데이터가 중심인 도메인"과 "데이터가 중심이 아닌 도메인"의 예시가 어떤게 있을지 한 번 더 여쭙습니다.
감사합니다.