서비스 메소드 작성 시 질문!

안녕하세요. 지식공유자 쥬쥬입니다 !

대부분의 로직은 Domain Model 안에서 작성하는 것을 권장합니다. 

일반적으로 아래와 같은 느낌으로 사용하고 있습니다.

ApplicationService (Primary Port) -- 사용 --> DomainService / DomainModel / Repository (Secondary Port) 

저는 잘 추상화된 것이 아니라면 서비스와 메소드의 depth를 늘리는 것을 선호하는 편은 아닌 것 같습니다.

궁금하신 용어들은 검색 해보시고 모호한 것들 추가로 문의주시면 감사합니다 !

감사합니다.

안녕하세요, 인프런 AI 인턴입니다.

서비스 메소드를 만들 때의 기준에 대한 규정이 명시적으로 존재하는 것은 아니지만, 일반적으로 몇 가지 고려해야 할 사항들이 있습니다. 서비스 메소드의 분리는 코드의 재사용성, 가독성 및 유지보수의 편의성을 높이기 위해 고려되어야 합니다.

• 로직의 재사용성: 비즈니스 로직이 다른 곳에서도 사용될 가능성이 있거나, 향후 그럴 가능성이 있는 경우 메소드로 분리하는 것이 좋습니다.

• 가독성: 하나의 메소드 내에 너무 많은 로직이 포함되어 있어 가독성이 떨어지는 경우, 이를 여러 개의 메소드로 분리하여 가독성을 개선할 수 있습니다.

• 단일 책임 원칙(SRP, Single Responsibility Principle): 한 메소드는 하나의 기능만을 담당해야 합니다. 따라서, 메소드가 여러 역할을 하고 있을 경우 기능별로 메소드를 분리하는 것이 좋습니다.

restaurantRepository.findById(restaurantId).orElseThrow()와 같은 조회 및 검증 작업을 자주 사용하게 되는 경우, 이를 별도의 서비스 메소드로 분리하거나 유틸리티 메소드로 만들어 코드의 재사용성을 높이고 중복 코드를 방지할 수 있습니다. 이는 개별 상황, 팀의 코딩 스타일 가이드라인 및 프로젝트의 구조에 따라 달라질 수 있으므로, 팀 내에서 컨벤션을 설정하고 따르는 것이 중요합니다.

스태틱 메소드로 만드는 경우는 주로 상태를 유지하지 않을 때(즉, 같은 입력값에 항상 같은 결과를 반환하고 외부 상태에 의존하지 않는 경우) 유용합니다. 반면, 서비스 레이어에서는 종종 특정 상태(예: 데이터베이스 연결 객체)에 의존하므로, 스태틱 메소드보다는 인스턴스 메소드로 구성하는 것이 일반적입니다.

결론적으로, 메소드 분리의 기준은 프로젝트의 특정 요구사항, 팀의 코딩 스타일 및 가독성과 유지보수성을 고려하여 결정되어야 합니다.