왜 사람들은 빈약한 도메인 모델을 만들어 활용할까?

그림 출처 - https://tinyurl.com/2ysllr6c

왜 사람들은 빈약한 도메인 모델을 만들까?

조영호님의 인프런 강의를 들으며 좋은 인사이트를 많이 얻을 수 있었는데, 강의를 모두다 수강한 뒤에 궁금한 것이 있었다.
우리 선배개발자님들은 왜 빈약한 도메인 모델을 관례처럼 만들까? 왜그럴까?

도메인 계층에는 객체지향 프로그래밍을 해야된다는 것을 머리속으로는 알고는 있지 않을까? 궁금함을 찾을 수 없어, 조영호님에게 직접 물어보았다.

왜 선배개발자님들은 빈약한 도메인 모델과 트랜잭션 스크립트 패턴을 작성하게 되었을까?

현 시점에 우리의 선배개발자님이 이렇게 된 배경에는 2가지가 있을 수 있다고 조심스럽게 조영호님께서 말씀해주셨다.

• 하나는 개발을 배우거나 실무에서 참고하는 기존 코드들이 이미 절차적으로 작성되어 있기 때문에 많은 사람들이 이 방식을 그대로 답습하고 있기 때문
• 다른 하나는 객체지향이 배우고 적용하기가 쉽지 않기 때문

위 2가지에 대해서 조금더 우리가 이해해보려는 시도를 해보자.

1. 기존 코드들이 이미 절차적으로 작성되어 있기 때문에

왜 기존 코드가 이미 절차적으로 작성되어 있었을까? 스프링부트를 사용하고 있는 우리는 스프링의 과거로 되돌아갈 필요가 있다.

과거로 되돌아가면, EJB > 스프링 프레임워크 > 스프링 부트 이렇게 기술이 진화했다는 사실을 알 수 있는데, 이 내용은 인프콘2023 토비님의 강의에서도 확인할 수 있었다.

스프링과 함께 더 나은 개발자 되기 - 이일민(토비).... 4:53

마찬가지로 영호님에게 한 질문에 대한 답변으로 EJB를 언급하셨다.

그럼 EJB가 무엇일까?
 EJB는 과거 서버 사이드 개발에서 자주 사용되던 기술로, 비즈니스 로직을 캡슐화하고 이를 서비스 계층에서 처리하게 하는 구조를 제공했다. 이 과정에서 데이터는 데이터베이스 테이블 같은 곳에 저장되며, 처리 로직은 별도로 구현된 비즈니스 컴포넌트(EJB)에 의해 수행되었다. EJB는 이 두 부분을 명확히 분리하는 구조를 장려했는데, 이는 객체지향적 관점에서 보면 데이터를 다루는 객체와 비즈니스 로직을 담당하는 객체가 분리된다는 의미다. 
 하지만 이로 인해 실제 구현에서는 데이터를 담는 객체(예: 데이터 전송 객체 DTO)와 비즈니스 로직을 처리하는 객체가 분리되다 보니, 객체지향적 설계보다는 절차적으로 처리하는 코드가 많아지게 되었다. 즉, 데이터를 다루는 객체와 로직을 처리하는 객체가 따로 존재하게 되면서 데이터와 로직이 긴밀하게 연동되지 못하고, 데이터를 넘겨받아 로직을 처리하는 순차적인 방식이 주가 되었던 것이다.결과적으로 이런 구조 때문에 비즈니스 로직을 구현할 때 객체지향적인 방식보다는, 데이터와 로직이 별도로 존재하는 절차지향적인 방식이 많이 사용되었다고 할 수 있다. ... EJB에 대한 설명

위 내용에 대해 추측컨데, 비지니스 로직과 데이터를 분리하는 개발에 대한 답습 때문에 또는 이미 만들어져 있는 코드가 영향을 미쳐 오늘날 우리의 개발자들이 빈약한 도메인 모델을 만드는 것을 당연하게 생각하게 된것은 아닐까?

2. 객체지향이 배우고 적용하기가 쉽지 않기 때문

 주관적인 생각으로 이 두번째가 빈약한 도메인 모델을 만들도록 유도하는게 아닐까? 라고 생각한다. 왜 객체지향은 배우기 어려울까? 이 부분에 대해서 주관적인 생각이 담긴 3가지 이유를 말하고 싶다.

첫번째는, 프로젝트 개발완료가 진짜 끝이라고 생각하기 때문이다. SI와 같은 외주업체에서는 프로젝트라는 것을 하게 되는데, 이때 프로젝트 개발 끝! 하면 더이상 해당 코드를 볼일이 없어지게 된다. 사실 유지보수를 하는 시점부터 프로젝트의 시작이라고 할 수 있음에도 불구하고 말이다. 읽기 쉬운 코드 1.1.1 프로젝트라고 생각해서 말하는 문제  챕터를 살펴보면 이런 이야기가 있다.

 소프트웨어 개발이 집을 짓는 것과 비슷하다고 생각했을 때, 가장 먼저 저지르는 실수는 프로그래밍을 프로젝트라고 생각하는 것입니다. 프로젝트는 시작과 끝이 있고, 마지막에 도달하면 모든 작업이 끝납니다. 하지만 소프트웨어 개발에서 작업이 끝나는 건 소프트웨어가 실패했을 때뿐입니다. 성공한 소프트웨어는 지속됩니다. 개발한 소프트웨어가 운 좋게 성공했다면 배포 이후 다음 배포를 위해 다시 개발 단계를 진행해야 하며, 이 과정은 몇 년 동안 이어질 수 있습니다. 매우 성공한 몇몇 소프트 웨어는 수십 년 간 개발이 지속되기도 합니다.    ... 읽기 쉬운 코드 中

 생명체가 자라듯 서비스가 시간이 지나면서 요구사항이 변경되는데, 이 변경 관리에 대해서 고민할 필요가 없었을 것이다.

두번째는, 우리가 코드를 작성할 때 생각하면서 코딩을 한다. 과거 멘토링을 할 때나 사이드프로젝트를 개발할 때 흔하게 범했던 실수 중 하나는 무엇을 만들지 기획에 대해서 심도있게 고민하지 않고, 바로 코딩하는 것이였다. 당연히 생각하면서 코딩하기 때문에 객체지향 프로그래밍을 하기 위한 도메인 간에 연결된 컨테스트맵을 고민하지 않게 된다. 그러면 당연히 객체지향적으로 프로그래밍할 수 없을 것이다. 도메인에 대한 역할/책임/협력에 대해서 충분히 고민했더라면, 생각하지 않으면서도 코딩할 수 있다는 사실을 깨달기가 어렵다고 생각한다.

마지막으로는, 객체지향이란 단어가 불명확하고 애매한 의미로 받아들여지기 때문이라고 생각한다. 우리가 Java 라는 언어를 처음 배울 때 가장 먼저 마주하게 되는 내용이 무엇인지 아는가? Java 는 객체지향언어라는 말을 한다. 그 뒤에 그 근거에 대해서 Class, Interface, 상속 등을 설명한다. 각 컴포넌트에 대한 설명을 먼저 한다. 당연하게도 공부를 하는 입장에서는 새로운 용어에 집착할 수 밖에 없고, 이는 곧 객체지향에 대해서 깊게 고민하기 보다는 '내가 어떻게 Java 로 프로그래밍할 수 있지?' 에 집착하게 되는 것 같다. 그래서 for, if, type 등을 고민하는게 아닐까? 초보 개발자들에게 당연히 도구에 대한 사용법을 알려주는 것이 나쁜 것은 아니지만- 객체지향이라고 했으니까, 객체지향이 무엇인지는 충분히 설명할 필요가 있지 않았을까 싶다.
 더하여, 객체지향 프로그래밍하면 나오는 SOLID 원칙이 있다. 이 단어에 대해서도 대부분의 사람들은 약어에 대해서 이해하고 있다. 하지만, 코드를 보면 SOLID 원칙에 대해서 고민했는지는 물음표를 남기곤 한다. 왜 그럴까? SOLID 원칙은 단순히 이론이기 때문에 그런걸까? 나의 생각에는 여전히 사람들이 객체지향에 대해서 애매하게 알고 있기 때문에, SOLID 원칙 또한 단순한 이론이라 간주하고 있는게 아닐까 라는 생각이 든다. 코드에서 SOLID 원칙을 직접 적용해보려고 하면 생각보다 많은 고민거리를 던져주곤 하는데, 심지어는 이렇게까지 코딩해야 하는 걸까? 라는 생각도 들곤 한다.

결론

여전히 우리의 개발 환경에는 빈약한 도메인 모델과 트랜잭션스크립트 패턴을 활용한 개발이 만연하다. 이것은 네카라쿠배라고 하는 대기업에서도 피해갈 수 없다. 그렇기 때문에 그들이 왜 그렇게 개발하는지 이해하려는 시도가 필요했고, 그 결과로 2가지 원인을 찾을 수 있었다.

• 하나는 개발을 배우거나 실무에서 참고하는 기존 코드들이 이미 절차적으로 작성되어 있기 때문에 많은 사람들이 이 방식을 그대로 답습하고 있기 때문
• 다른 하나는 객체지향이 배우고 적용하기가 쉽지 않기 때문

단순히 빈약한 도메인 모델과 트랜잭션스크립트 패턴을 사용한다고 싫어하지 말자. 다 이유가 있었고, 받아들이고 어떻게 행동하면 더 나은 소프트웨어를 만들 수 있는지 고민하자.

[참고자료]

질문 - https://www.inflearn.com/community/questions/1385602

왜 선배개발자님들은 절차지향이였을까? - 인프런 | 커뮤니티 질문&답변

토비님의 2023 인프콘 강의 - https://inf.run/VsWGx

학습 페이지