2020년 12월 17일, Daily Comment

Service layer에 대한 고찰

1. 정의
   Domain model을 묶어서 소프트웨어에서 사용 가능한 핵심 작업 집합을 설정하는 계층
   
   
2. 등장배경
   도메인 모델 여러개를 불러와 요청을 가공하고 비즈니스 로직을 호출하고
   응답을 조정해서 또 다른 비즈니스 로직을 호출하는 layer의 필요성
   
   
3. Service layer의 책임
   
   • 핵심 로직은 Business layer에 두고, Service layer는 얇게 유지하는 것이 좋다.
   • Service 영역은 도메인의 핵심 비즈니스 코드를 담당하는 영역이 아니라
     인프라스트럭처(데이터베이스) 영역과 도메인 영역을 연결해주는 매게체 역할이라고 생각
     
   • 행위 기반으로 네이밍하자

   1 2 3 4 5 6

   // Worst public class MemberService{} // 해당 클래스의 책임(행위)이 명확하지 않음 // member domain의 모든 로직이 해당 클래스로 모이게 된다. // findById 메서드 하나를 사용하고 싶어도 Service 전체를 주입받아야 한다.

   1 2 3 4 5

   // Good public class MemberFindService{} // 객체를 행위 기반으로 바라보고 행위 기반으로 네이밍을 주어, // 자연스럽게 책임을 부여하는 것이 좋다.

   
   

리팩토링 대원칙

1. The first time you do something, you just do it.
   처음은 그냥 해라.
   
   
2. The second time you do something similar, you wince at the duplication, but you do the duplicate thing anyway.
   두번째는 복붙해서 해라.
   
   
3. The third time you do something similar, you refactor.
   세번째부터 리팩토링해라.
   

참고: ThreeStrikesAndYouRefactor

Code convention

SonarQube
intelliJ, SonarLint plugin