답변:
예외와 함께 개별 비즈니스 규칙 검사를 나타내는 것을 의미한다면, 이것이 좋은 생각이라고 생각하지 않습니다. 여러 번 실패 상태를 두 개 이상보고해야하며 첫 번째 상태에서 멈추지 않아야합니다.
반면에, 나는 모든 규칙 을 확인한 다음 요약과 함께 예외 를 던지는 것이 좋습니다.
이 예에서 예외를 제기하는 것은 나쁜 생각이라고 생각합니다. 사용자가 작업을 시작하기 전에 권한이 부여되지 않았지만 여전히 일부 기능을 수행하도록 허용 한 다음 이미 작업을 완료 한 후 메시지와 함께 사용자에게 경고를 표시하는 경우 이는 잘못된 설계입니다.
비즈니스 규칙을 시행하기 위해 예외를 사용하는 것은 좋은 디자인이 아닙니다.
좋은 비즈니스 로직을 만드는 데 예외를 던지는 가치가 무엇인지 알 수 없습니다. 시스템 작동에 예기치 않은 조건을 해결하기위한 시스템을 사용하지 않는 비즈니스 로직 처리에는 수십 가지 접근 방식이 있습니다.
되는 예상 비즈니스 로직에 조건이 충족되지 않습니다; 이것이 처음에 필요한 이유이며, 예기치 않은 I / O 실패, 메모리 부족 및 널 참조를 처리하는 동일한 메커니즘을 피기 백하고 싶지 않습니다. 이는 시스템 장애이지만 충족되지 않은 비즈니스 조건을 감지하는 것이 시스템의 성공적인 작동입니다.
또한 의도하지 않은 결과에 대해 익히는 시스템입니다. 특정 시점에서 예외를 잡아야하므로 의도하지 않은 어딘가에 새 비즈니스 규칙 예외가 발생하거나 실제로 의도하지 않은 예외를 잡는 비즈니스 규칙을 찾는 코드가있을 수 있습니다. 그것을 위해. 그렇습니다. 이러한 조건은 좋은 코딩 방법으로 설명 할 수 있지만 둘 이상의 개발자가 작업하는 사소한 시스템에서는 실수가 발생하며 값 비싼 실수가 아니기를 바랍니다.
비즈니스 규칙을 표현하는 것은 한 가지입니다.
사용자 경험에 대해 생각하십시오. 사용자가 영업 사원이 아닌 경우, 왜 그들에게 '송장을 만들'라는 버튼 줄 전혀를 ?
그것은 전적으로 무엇을하고 있는지에 달려 있습니다.
먼저, 실제 행동은 무엇입니까? 누군가 자신의 정보를 입력하는 경우 거부 및 기본적으로 "그렇게 할 수 없습니다"라는 대화 상자가 올바른 것입니다. 양식 입력으로 작업하는 데이터 입력 담당자 인 경우 대화 상자가 적합 할 수 있으며 데이터 입력 담당자는 유효하지 않은 양식을 특수 파일에 넣을 수 있습니다. 일괄 처리를 수행하는 경우 작업을 중단하지 말고 플래그를 지정하고 다음으로 이동하십시오.
동작이 있으면 구현 방법을 결정해야합니다. 예외를 발생시키는 비즈니스 규칙 검사기를 갖는 것이 좋습니다. 리턴 코드를 리턴하고 전달하는 것은 잘못 될 수있는 일이며, 잘못된 항목이 더 이상 발생하는 것을 원하지 않습니다.
성능 비용에 대해 걱정하지 마십시오. 개인이 데이터를 입력하는 경우 관련된 다른 시간에 비해 사소합니다. 일반적으로 인간은 그 시스템에서 가장 많은 시간을 소비합니다. 배치 작업의 경우 예외로 인해 성능 문제가 발생하면 너무 많은 불량 레코드를 입력하게되며 실제로 이러한 모든 처리 및 재 입력은 예외보다 더 큰 문제가됩니다.
일관성 있고 강력하고 잘 설계된 예외 API를 갖는 것이 매우 적합합니다. 이것을 사용하여 비즈니스 규칙을 시행하는 것도 적절할 수 있습니다. 실제로 내 경험상 비즈니스 규칙이 복잡할수록 이러한 방식으로 처리 될 가능성이 높아집니다. 권위있는 분기 논리를 작성하는 것보다 예외가 예상되는 시스템을 작성하는 것이 쉽지는 않지만 종종 쉬운 일입니다.
즉, 한 문장으로 설명 할 수있는 간단한 규칙은 일반적으로 규칙에 따라 예방 적 또는 권위적인 방식으로 구현되어야합니다. 그러나 다차원 적이며 3 개 또는 4 개 이상의 요소가 필요한 규칙이있는 경우 (특히 이러한 요소의 선택이 하나 이상의 다른 요소를 기반으로하는 경우) 예외 코딩을 유지 관리하기가 더 쉬울 수 있습니다. 이러한 경우에는 종종 논리 경로에 발생해야하는 많은 전구체 예외 (작업이 수행 될 수없는 이유를 확인)가 수행되고 (또는 그 반대) 보안이 작동하지 않습니다 (작업이 승인되었는지 확인) ), 때로는 확인해야 할 권위있는 누적 논리가있을 수 있습니다 (하위 / 조상 가용성, 객체를 넣어야하는 전구체 상태 등).
이러한 유형의 예외 처리에서 파생되는 이점 중 하나는 프로젝트의 여러 영역에서 전조 예외를 분리하여 재사용 할 수 있다는 것입니다. (이것은 Aspect 지향 프로그래밍의 본질입니다.)이를 통해 일반 비즈니스 규칙의 특정 측면을 독립적이고 유지 관리 가능한 구성 요소로 캡슐화합니다. 일반적으로 이러한 구성 요소는 1-1에 해당하는 오류 메시지와 일치합니다. (때로는 여러 다른 예외를 발생시키는 하나의 구성 요소가 있지만 여러 구성 요소에서 동일한 예외가 발생하지 않아야합니다.)
제 생각에는 예외 기반 시스템을 설계하는 것이 더 어렵고 모든 N 레벨에서 예외 프로세스를 빌드해야하기 때문에 초기 개발 시간이 더 깁니다. 그러나 이러한 시스템은 일반적으로 훨씬 더 안정적입니다. '실패하지 않을'시스템을 설계하는 것은 불가능하지만 예외 기반 설계의 이점은 항상 장애를 예상한다는 것입니다. 대부분의 사람들에게이 과정은 반 직관적 일 수 있습니다. 길 찾기를 요청하고 다른 사람에게 모든 거리를 알려주지 말아야합니다.