서비스로 군만두 주세요!

위키백과에서는?

위키백과 Service layer pattern 링크

Rationale (합리성)

Grouping services into functional layers reduces the impact of change. Most changes affect only the layer in which they're made, with few side-effects that impact other layers. This fundamentally simplifies service maintenance.
서비스를 기능 단위 레이어로 그룹화 하면 변경에 의한 영향을 줄일 수 있다. 대부분의 변경 사항은 다른 레이어에 별다른 사이드 이펙트 없이 해당 레이어에서만 적용된다. 이는 서비스의 유지보수를 근본적으로 단순화한다.

The service reusability principle dictates that services should be designed to maximize reuse. Similarly, the service composability principle advocates designing services so that they can be composed in various ways. Both principles require that a service contain only a specific type of logic e.g., either reusable or process-specific logic. Restricting each layer to a particular functionality, simplifies the design of the service.
서비스 재사용 가능성의 원칙은 서비스가 재사용을 극대화하도록 설계되어야 한다고 규정하고 있다. 마찬가지로, 서비스 종합성 원칙은 다양한 방법으로 구성할 수 있도록 서비스를 설계하는 것을 지지한다. 두 원칙 모두 서비스에는 재사용 가능한 로직 또는 프로세스별 로직 등 특정 유형의 로직만 포함하도록 요구하고 있다. 각 계층을 특정 기능으로 제한하여 서비스 설계를 단순화한다.

무슨 말이야?

일단 "유지보수를 근본적으로 단순화한다." 라는 단어가 눈에 띄인다.
다음으로는 "재사용을 극대화", "각 계층을 특정 기능으로 제한하여 서비스 설계를 단순화" 같은 말이 보인다.

• 유지보수를 쉽게
• 단순화
• 재사용성

이렇게 세가지 키워드를 위해 서비스를 쓴다는 것 같다.
조금 더 자세히 알기 위해 '서비스' 라는 단어를 직접적으로 쓰는 프레임워크를 살펴봤다.

다른 곳에서 봤던 서비스

Providers | NestJS
Service (Spring Framework)

나는 Service 라는 단어를 NestJS에서 처음 봤고, Spring을 공부하며 @Service 라는 어노테이션에서 두번째로 보게 되었다.

위의 링크 중 스프링의 문서에서

annotated class is a "Service", originally defined by Domain-Driven Design (Evans, 2003) as "an operation offered as an interface that stands alone in the model, with no encapsulated state."
도메인 주도 설계(Evans, 2003)에 의해 "캡슐화된 상태 없이 모델에 단독으로 인터페이스로 제공되는 연산"으로 정의

이런 글을 볼 수 있다.

스프링에서 @Service 어노테이션이 붙은 클래스는 Controller가 사용하며,
위의 글과 사용하는 방법을 생각해보면 비즈니스 로직을 가지고 Controller와 Model의 연결점이 된다는 말이 된다.

웹 어플리케이션에서 Controller는 request와 response 로 부터 자유로울 수 없다.
만약 저 두가지 값에 변화가 생기고, Controller가 직접 비즈니스 로직을 가진다면
코드에 큰 변화가 일어날 수 밖에 없을 것이다.

하지만, 실제 비즈니스 로직에 대한 부분을 Service가 담당하게 된다면
Controller가 변하더라도 Service는 그대로 사용하면 되기에 유지보수도 쉬워지고 코드를 재사용 할 수도 있게 된다.

뭔가 설명이 건너뛴 것 같고 엉성한데...

그렇다. 자세히 설명하려면 지난번에 언급했던 다층 구조 에 대해 깊이 이해하고 이 부분에 대한 설명도 들어가야 하는데
아직 내가 그런 이해도가 높지가 않아서 어디를 더 자세히 봐야하는지 잘 모르겠다.

언젠가 이런 개념들에 대해 이해가 깊어지고 나면 새로 작성할지도 모르겠다.

NestJS에서 Service를 처음 봤을 땐 뭔지 몰랐는데,
스프링을 공부하면서 다시 Service를 보게 되니 조금 더 자세히 찾아보게 되고
Controller에 직접적으로 비즈니스 로직을 넣으면 안되는 이유도,
그걸 Service라는 이름으로 분리해서 사용해야 되는 이유도 조금은 알게 되었다.

지금은 그 정도면 괜찮지 않을까 자기만족을 하며 글을 마친다.