비즈니스 로직

Business logic

컴퓨터 소프트웨어에서 비즈니스 로직 또는 도메인 로직은 데이터의 생성, 저장 및 변경 방법을 결정하는 실제 비즈니스 규칙을 인코딩하는 프로그램의 일부입니다.데이터베이스 관리, 사용자 인터페이스, 시스템인프라스트럭처 표시 또는 프로그램의 다양한 부분을 일반적으로 연결하는 등 하위 수준의 세부 사항과 관련된 나머지 소프트웨어와는 대조됩니다.

상세 및 예시

비즈니스 로직:

  • 비즈니스 객체가 서로 상호 작용하는 방식을 규정합니다.
  • 비즈니스 개체에 액세스하고 업데이트하는 경로 및 방법을 적용합니다.

업무 규칙:

  • 실제 비즈니스 객체 모델링(예: 계정, 대출, 여행 일정, 인벤토리)

비즈니스 로직 구성 요소:[1]

  • 참가자(사용자 또는 소프트웨어 시스템)에서 다른 참가자에게 문서 또는 데이터를 전달하는 순서 태스크인 워크플로우.

비즈니스 로직은 비즈니스 [2]규칙과 구별되어야 합니다.비즈니스 로직은 데이터가 어떻게 변환 또는 계산되는지, 그리고 데이터가 사람 또는 소프트웨어에 어떻게 라우팅되는지를 결정하는 엔터프라이즈 시스템의 부분입니다(워크플로우).비즈니스 규칙은 비즈니스 정책의 공식 표현입니다.프로세스 또는 프로시저가 되는 것은 비즈니스 논리이며, 프로세스도 프로시저가 아닌 것은 비즈니스 규칙입니다.새로운 방문자를 환영하는 것은 취해야 할 단계로 구성된 프로세스(워크플로우)인 반면, 모든 새로운 방문자를 환영해야 한다는 것은 비즈니스 규칙입니다.또한 비즈니스 로직은 절차적인 반면 비즈니스 규칙은 [3]선언적인 것입니다.

예를 들어, 전자 상거래 웹 사이트에서는 방문자가 쇼핑 카트에 항목을 추가하고 배송 주소를 지정하며 결제 정보를 제공할 수 있습니다.웹 사이트의 비즈니스 로직에는 다음과 같은 워크플로우가 포함될 수 있습니다.

  • 체크아웃 중에 발생하는 일련의 이벤트, 예를 들어 배송지 주소를 먼저 묻고 청구지 주소를 묻는 여러 페이지 양식, 다음 페이지에는 지불 방법이 포함되어 있으며 마지막 페이지에는 축하 메시지가 표시됩니다.

또, 다음의 Web 사이트의 비즈니스 룰도 있습니다.

  • 항목 설명 페이지에서 항목을 두 번 이상 추가하면 해당 항목의 수량이 증가합니다.
  • 방문자의 주소, 이메일 주소 및 신용카드 정보가 따라야 하는 특정 형식입니다.
  • 신용 카드 네트워크와 대화하기 위한 특정 통신 프로토콜

웹 사이트 소프트웨어에는 비즈니스 로직이나 비즈니스 규칙의 일부로 간주되지 않는 다른 코드도 포함되어 있습니다.

  • 사이트의 색상, 외관, 배경 이미지, 탐색 구조를 정의하는 HTML 등 핵심 비즈니스 데이터와 관련이 없는 주변 콘텐츠
  • 일반적인 오류 처리 코드(예를 들어 HTTP 오류 코드 500 페이지를 표시함)
  • 웹 서버가 사이트를 시작할 때 실행되는 초기화 코드. 이 코드는 시스템을 설정합니다.
  • 사이트의 모든 부분이 정상적으로 동작하고 있는지 확인하기 위한 인프라스트럭처 감시(예: 과금 시스템 이용 가능)
  • 네트워크 접속, 데이터베이스로의 오브젝트 전송, HTTP POST 이벤트를 통한 사용자 입력 해석 등을 위한 범용 코드.

비즈니스 로직 및 계층/계층

이론상 비즈니스 로직은 3계층 아키텍처의 중간 계층을 차지합니다.

비즈니스 로직은 프로그램 어디에나 있을 수 있습니다.예를 들어 주소의 특정 형식을 지정하면 비즈니스 로직에서 지정된 필드에 정확히 대응하는 열이 있는 데이터베이스 테이블을 생성하고 잘못된 데이터가 추가되지 않도록 유형 검사를 추가할 수 있습니다.

비즈니스 로직은 자주 바뀝니다.예를 들어 온라인 소매업체가 새로운 국가로 제품을 배송하기 시작하면 허용되는 주소 형식 집합이 변경될 수 있습니다.따라서 비즈니스 로직을 구현하는 코드를 비교적 분리하거나 느슨하게 결합하는 것이 바람직하다고 생각되는 경우가 많습니다.이로 인해 비즈니스 로직을 변경하면 코드의 일부만 약간의 코드 변경이 필요할 가능성이 높아집니다.거리가 멀지만 강하게 결합된 코드는 프로그래머가 필요한 일부 변경만 수행하고 시스템의 일부를 놓쳐 잘못된 [4]작동을 초래할 위험도 더 커집니다.

멀티티어 아키텍처는 데이터 액세스 계층이나 서비스 계층과 같은 다른 계층 또는 계층과 분리된 비즈니스 로직 계층을 생성하여 이러한 디커플링을 공식화합니다.각 계층은 다른 계층에 있는 코드에 대해 최소한의 정보만 "알고" 있기 때문에 필요한 작업을 수행할 수 있습니다.를 들어, 모델-뷰-컨트롤러 패러다임에서는 모든 비즈니스 로직이 모델에 집중된 상태에서 컨트롤러와 뷰 계층을 가능한 한 작게 만들 수 있습니다.전자상거래의 예에서는 컨트롤러가 체크아웃 시퀀스의 웹 페이지 순서를 결정하고 이메일, 주소 및 결제 정보가 비즈니스 규칙을 충족하는지 검증할 책임이 있습니다(데이터베이스 자체 또는 하위 수준의 데이터베이스 액세스 코드에 맡기는 것이 아니라).

다른 패러다임이 가능합니다.예를 들어 비교적 단순한 비즈니스 엔티티에서는 범용 뷰와 컨트롤러가 데이터베이스 오브젝트에 액세스할 수 있습니다.데이터베이스 오브젝트에는 어떤 포맷을 수용하고 어떤 변경이 가능한지(데이터베이스 모델이라고 불립니다)와 관련된 모든 비즈니스 로직이 포함되어 있습니다.

일부 계층형 스킴에서는 개별 애플리케이션 계층 또는 서비스 계층을 사용하거나 비즈니스 로직 계층이 이들 중 하나와 동일하다고 간주합니다.

도구 및 기술

BRMS([5]Business Rule Management System)를 사용하여 절차 코드에서 비즈니스 로직을 추출할 수 있습니다.

소프트웨어 개발의 비즈니스 규칙 접근법은 BRMS를 사용하여 비즈니스 로직을 다른 코드로부터 매우 강력하게 분리합니다.사용자 인터페이스 관리 시스템은 비즈니스 로직과 다른 코드를 강력하게 분리하기 위해 사용되는 또 다른 기술입니다.매직 푸시 버튼은 "안티 패턴"으로 간주됩니다.이 경우 바람직하지 않은 제약이 발생하여 비즈니스 로직을 유지하기가 어렵습니다.

도메인 모델은 비즈니스 규칙에 필요한 데이터 스토리지 유형을 추상적으로 표현한 것입니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Steven Minsky (2005-03-27). "The Challenge of BPM Adoption". eBizQ.
  2. ^ "Definition of business logic". 2013-12-24.
  3. ^ William Ulrich. "OMG Business Rules Symposium" (PDF). Archived from the original (PDF) on 2013-12-24.
  4. ^ Khawar Zaman Ahmed & Cary E. Umrysh (2001-10-17). "Introduction to Enterprise Software". Developing Enterprise Java Applications with J2EE and UML. Addison-Wesley. ISBN 0-201-73829-5.
  5. ^ Owen, James (September 19, 2003). "Bring business logic to light". Enterprise Java. InfoWorld. Retrieved 2020-07-21.

추가 정보

  • Brett McLaughlin (March 2002). "Business Logic, Part 1". Building Java Enterprise Applications, Vol I: Architecture. O'Reilly and Associates. ISBN 0-596-00123-1. McLaughlin은 애플리케이션의 비즈니스 레이어를 구현하기 위한 전면 패턴에 대해 설명합니다.
  • Kathy Bohrer (November 1997). "Middleware isolates business logic". Object Magazine. New York, USA: SIGS Publications, Inc. 7 (9): 41–46. ISSN 1055-3614.
  • Harumi Kuno; Mike Lemon; Alan Karp & Dorothea Beringer (2001). "Conversations + Interfaces = Business Logic". In F. Casati; D. Georgakopoulos & M.-C. Shan (eds.). Technologies for E-Services: Second International Workshop, TES 2001, Rome, Italy, September 14–15, 2001, Proceedings. Lecture Notes in Computer Science. Vol. 2193. Springer Berlin / Heidelberg. ISSN 0302-9743.
  • Volker Turau(2002년).어플라이드 컴퓨팅, 스페인 마드리드에 2002년 ACM심포지엄:웹과 e-비즈니스를 응용 프로그램의"웹 기반 데이터 입력 응용 프로그램의 자동 생성을 위한 프레임워크 XML기반". 논문집.ACM프레스. pp. 1121–1126. 아이 에스비엔 1-58113-445-2. — Turau 애플리케이션 프레임워크, 병렬로 상대적으로지만 협력하고 독립 트랙을 따라 진행할 각 개발 허용하는 자바 Servlets과 자바 서버 페이지는 비즈니스 로직과 발표 논리 간의 구분 할 수 있게 하는을 사용하여 구현한를 제공한다.
  • 파우, L.-F.&Vervest, P.H.M.(2003-12-08)."네트워크 기반 사업 공정 관리:통신망 안에서 묻어 두는 비즈니스 논리".ERIM 보고서 시리즈 연구 관리에.에라스무스 대학교.hdl:1765/1070.{{ 들고 일기}}:Cite저널 journal=( 도와 주)— 포와 Vervest 사업 논리의 관점이 네트워크 관점에서 사업 자원의 배분을 최적화하는 배우들의 다양한 이유로 분산된 애플리케이션에 기초하는 통신망엤던 1가지 이슈 때문이었습니다에 대한 접근 방식을 개발이 필요하다.

외부 링크