비즈니스 로직과 서비스 계층

나는이 대답을 읽었습니다 : https://softwareengineering.stackexchange.com/a/234254/173318 이해하십시오.

비즈니스 규칙 은 실제 비즈니스 단계 목록 (코드 없음)을 나타냅니다.

비즈니스 로직 (Business Logic) 은 비즈니스 규칙을 코드로 변환하는 프로세스 및 이러한 코드를 "비즈니스 로직"으로 처리합니다.

그리고 서비스 계층은 무엇에 사용됩니까? 이 답변을 읽으면 비즈니스 로직과 다르지 않습니다 https://stackoverflow.com/a/4817935/4190539

서비스 계층이 비즈니스 로직과 저장소를위한 장소입니까?

design-patterns object-oriented-design business-logic

— 카카시
소스

"서비스 계층"은 일반적인 용어이며 원하는 것을 포함하거나 포함 할 수 있습니다. 당신이 인용 한 SO 질문은 "ASP.NET MVC의 서비스 계층"에 관한 것이 었습니다. 당신은 의도적으로 후자에 대해 이야기하고 있습니까? 아니면 단순히 차이점을 그리워 했습니까?

— Doc Brown

그것이 내가 지금까지 얻은 것입니다. 그러나 나는 그들 모두에 대한 당신의 설명을 듣고 싶습니다.

— 카카시

"서비스 계층"은 아키텍처 용어입니다. 이는 다중 계층 아키텍처 의 중간 , 사용자 상호 작용 계층 아래, 데이터 액세스 계층 위에있는 시스템의 일부를 나타냅니다 .

비즈니스 로직은 서비스 계층에서 구현 되어 비즈니스 규칙 을 시행 할 수 있습니다 .

그러나 비즈니스 로직이 다른 계층으로 끝나는 경우가 있습니다. 예를 들어, 사용자 경험을 향상시키기 위해 일부 비즈니스 규칙이 사용자 상호 작용 계층에 적용됩니다 (예 : 서버로 왕복하지 않고도 확인할 수 있도록 Javascript로 작성된 유효성 검사기). 이 경우 서비스 계층은 일반적으로 시행을 복제합니다.

다른 비즈니스 규칙은 데이터베이스 계층에서만 시행 할 수 있습니다 (예 : 동시성 문제 (라이브러리 북을 체크 아웃 할 수있는 응용 프로그램 상상)) 또는 성능 문제 (바쁜 판매원의 연간 커미션을 계산하는 프로그램 상상) 복잡한 수수료 구조).

— 존 우
소스

서비스 디렉토리가 있고 bussiness 논리를 넣고 저장소, 다른 서비스, 유효성 검사를 주입하는 장소로 클래스를 포함하면 괜찮습니까?

— 카카시

그렇습니다. 데이터 액세스를 포함한 다른 서비스를 서비스 계층에 주입하는 것은 당연합니다. 데이터를 어떻게 든 저장해야하며 올바르게 작성하면 자체적으로 수행 방법을 모릅니다.

— John Wu

저장소에 비즈니스 코드 권한이 없어야합니까? 그것은 리포지토리가 유효성 검사, 필터 또는 strtolower와 같은 다른 strijg 조작에서 명확해야 함을 의미합니까?

— 카카시

반드시 (내 게시물에 이미 두 가지 예를 제시 한 것은 아님), 가능한 한 많은 비즈니스 로직을 서비스 계층으로 옮기는 것이 좋습니다.

— John Wu

오, 그래, 내가 볼 수있는 저장소 패턴 코드가 있습니까?

— Kakashi