도메인과 서비스 그리고 개발자 마음가짐

 

우아한 테크코스 1번째 미션을 개발을 진행하며 고민했던 내용들과 그에 대한 피드백을 적은 내용이다.

 

1. 도메인과 서비스는 무엇이 다른가? 도메인 역할? 서비스 역할?

 

Q1. 도메인은 비즈니스 로직을 가질 것이다. 서비스는 비즈니스 로직을 가질까?

 

이 질문에 대답하기 앞서, 비즈니스 로직을 알아야 한다.

 

비즈니스 로직이란 우리에게 주어진 요구사항의 핵심 로직을 말한다.

예를 들어, DTO변환과 같은 로직은 기술적인 로직이고, 1000원짜리 로또를 구매하는 로직을 작성하는 것은 비즈니스 로직이라 할 수 있다.

먼저 위 질문에 대한 내 대답은 YES였다.

하지만 피드백에서는 어떻게 설계하느냐에 따라 다르다고 하였다. 참 어렵다.

 

그렇다면 내가 생각하는 도메인에 속하는 비즈니스 로직은 무엇이고, 서비스에 속하는 비즈니스 로직은 무엇일까?

 

도메인에 속하는 비즈니스 로직은 명확한 로직이다. 명확하게 해당 도메인에 포함되어 도메인의 내부 상태를 변경하거나 자신의 상태를 갖고 해결할 수 있는 로직이 들어가야 한다.

서비스에 속하는 비즈니스 로직은 명확하게 도메인만 필요한 것 외에 다른 어려운 기술적인 요소가 필요한 경우, 서로 다른 도메인이 상호작용해야 하는 경우 필요하다고 생각한다. 즉, 도메인 로직을 조합하여 실행하는 것이라 볼 수 있다.

 

 

Q2. 도메인 역할? 서비스 역할?

도메인의 역할은 비즈니스 핵심 로직을 정의해 놓은 것이다. 그렇기에 정말 중요하다.

요구사항이 변경되지 않는다면 쉽게 변경되지 않아야 하며, 그렇기에 다른 기술적인 코드에 영향을 받아서는 안된다.

 

서비스의 역할은 컨트롤러와 도메인 사이의 방파제라고 할 수 있다.

변경에 취약한 컨트롤러가 도메인과 직접적으로 연관되어 있다면 마찬가지로 도메인도 변경에 취약해질 수 있기 때문에, 컨트롤러와 도메인 사이의 거리를 멀어지게 하는 역할을 서비스가 하는 것이다.

 

하지만 무조건적으로 멀리 보내는 것은 좋지 않다. 적당히…. 그렇다면 어디까지..!? 이것도 궁금하고 앞으로 알아가야 할 것 같다.

---

2. 개발하며 알아야 할 마음가짐

개발에 정답이 있다는 생각을 버려라!!

우리는 항상 정답을 찾곤 한다. “이것이 맞는 걸까? 아니면 다른 것이 맞는 걸까?”

또, 우리는 항상 이렇게 질문한다.

“제가 이렇게 개발했는데 맞나요? 잘못된 걸까요?”

혹자는 이렇게 답변한다.

“이렇게 해야 해. 그건 잘못된 거야. 틀렸어”

 

하지만 개발에는 정답이 없다.

개발한 의도가 중요하다.

• 어떤 이유 때문에 이런 설계를 진행했는지?
• 이렇게 함으로써 장단점이 무엇이 있는지?

물론 정해진 규칙이 있을 수 있다. 하지만, 정해진 규칙을 깨뜨릴 만큼 합리적인 이유가 있다면 규칙을 지키지 않아도 되는 예외도 있을 수 있다.

 

하지만 그러기 위해 어떤 생각을 가지고 코드를 작성했는지, 그것이 합리적인지 설득할 수 있어야 한다.

위 생각을 지니고 개발을 해야 할 것 같다.

 

Q의문점. 여러 사람이 하나의 코드를 작성할 때 이해를 위해 통일성이 중요하다고 생각했는데, 이유가 확실하다면 예외 케이스도 받아들이는 게 괜찮은 걸까요..

→ 네오의 대답 : 난 괜찮아!

 

[번외]

Q. Getter를 무조건 지양해야 하는가?

먼저 이 질문에 대한 답은 “아니다"이다.

도메인 내부에서 구현될 수 있는 핵심 비즈니스 로직을 외부에서 구현하지 말라는 뜻이라고 한다.

 

나는 이전에 getter는 어쩔 수 없이 사용되어야 한다며 생각 없이 사용했던 경우가 많았던 것 같다. 위 의도를 가지고 사용하기 전 꼭 필요한 Getter인가를 생각해야 할 것 같다.

 

Q. 객체의 그래프?

이번 피드백에서 객체 그래프라는 말을 처음 들었다.

객체 그래프는 객체들 간의 관계를 시각적으로 표현한 구조라고 한다. 객체들이 서로 연결된 방식. 즉, 객체들이 다른 객체를 참조하거나 소유하는 방식을 나타낸다.'

 

하나의 객체가 다른 객체를 참조하여 메소드를 호출한다면 이 두 개 객체는 서로 연결된 것이다.

“객체에 메시지를 던져라.” 가 객체지향에서 자주 하는 말이긴 하지만 무조건 메시지만 던진다면 객체가 연결된 깊이가 길어져 무한 늪에 빠질 수 있다.

 

그렇기에 getter, dto 등을 활용하여 적절한 시점에 끊어 주는 것이 중요하다.

 

[Reference]

- 네오의 1차 피드백