"비즈니스 로직"은 "모든 타사 코드"가 아닌 경우 실제로 무엇을 의미합니까?


25

사람들이 직장에서나 온라인에서 비즈니스 로직에 대해 많이 이야기하는 것을 들었습니다.이 사이트에서 이에 대한 몇 가지 질문을 읽었지만이 용어는 여전히 의미가 없습니다. 예를 들어, 다음은 종종 내가 볼 수있는 몇 가지 설명입니다.

  • "비즈니스 로직은 실제 비즈니스 규칙을 인코딩하는 프로그램의 일부입니다." 내가 읽은 대부분의 정의는 이와 같은 원형입니다.

  • "비즈니스 로직은 특정 애플리케이션에 고유 한 모든 것입니다." 실수로 기존 타사 소프트웨어를 사용할 수있는 바퀴를 재발견하지 않는 한 이것이 "특정 응용 프로그램은 비즈니스 논리에 지나지 않습니다"와 어떻게 다른지 알 수 없습니다. 따라서 질문 제목입니다.

  • "데이터 액세스 계층 위와 GUI 계층 아래에 ​​비즈니스 로직 계층이 있어야합니다." 내가 작성한 코드에서 데이터베이스 접근자는 액세스 해야하는 데이터를 알아야하고 UI 코드는 올바르게 표시하기 위해 표시되는 내용에 대해 많이 알아야하며 실제로는 할 일이 없습니다. 클라이언트와 서버간에 데이터를 전달하는 것 이외의 두 위치 그렇다면 실제로 비즈니스 로직 계층으로 들어가는 것은 무엇입니까?

  • "비즈니스 로직은 프리젠 테이션 로직과 분리되어야합니다." 우리가받는 대부분의 기능 요청은 비즈니스상의 이유로 프리젠 테이션 로직을 변경하는 것입니다. 비즈니스 규칙 중 하나가 기본적으로 미국 정부 채권 가격을 32 번째 표기법으로 표시하는 경우 (사용자가 구성 할 수있는 UI 제공) 프리젠 테이션 논리는이 규칙이 완전히 구현되지 않은 경우이 규칙이 존재한다는 사실을 최소한 알아야합니다. 또한 UX 디자인의 주요 부분은 사용자가 소프트웨어가 구현하려는 비즈니스 규칙을 이해하도록 돕는 것 같습니다.

실제로 비즈니스 로직 만 수행하는 팀에 소속되어 있고 모든 비 비즈니스 로직이 다른 팀에 의해 수행되고 있습니까? 아니면 "비즈니스 로직"의 전체 개념이 특정 응용 프로그램이나 아키텍처에서만 작동 할 수있는 별도의 개체입니까?

답변을 구체적으로 작성하려면 : Domino 's Pizza 앱을 다시 구현해야한다고 가정하십시오. 비즈니스 로직은 무엇이며 해당 앱의 비 비즈니스 로직은 무엇입니까? 그리고 피자 정보의 대부분이 데이터 액세스 및 프리젠 테이션 레이어로 유출되지 않고 피자 주문 비즈니스 로직을 자체 코드의 "레이어"에 넣는 것이 어떻게 가능할까요?

업데이트 : 우리 팀은 아마도 90 %의 UI 코드를 수행하고 비즈니스 로직이라고 부르는 것의 대부분은 다른 팀이나 회사에서 온다는 결론에 도달했습니다. 기본적으로 우리의 응용 프로그램은 모니터링재무 데이터 및 거의 모든 기능은 사용자가보고있는 데이터와 보는 방식을 사용자 지정할 수있는 방법입니다. 구매 또는 판매는 진행되지 않으며 (우리는 그렇게하는 회사의 다른 앱과 비트를 통합하지만) 실제 데이터는 많은 외부 소스에서 제공됩니다. 그러나 사용자는 "모니터"의 사본을 다른 사용자에게 보내는 것과 같은 작업을 수행 할 수 있으므로 비즈니스 로직으로 간주 될 수있는 세부 정보를 처리 할 수 ​​있습니다. 실제로 현재 백엔드 코드 중 일부와 통신하는 모바일 앱이 있으며 이상적인 세계에서 UI와 공유하기를 원하는 프론트 엔드 코드의 부분을 정확히 알고 있습니다 (기본적으로 quasi-MVC의 M). 나는 그것이 우리를위한 BLL 인 것 같아요.

나는 "비즈니스 로직"이 무엇을 의미하는지에 대해 더 구체적으로 이해했기 때문에 user61852의 대답을 받아들이고 있습니다.


1
"휠 재발견"깔개 아래의 모든 발판, 인프라, 보일러 플레이트, 라이브러리 코드를 쓸어 넘기는 것이지만 실제로는 좋은 코드입니다. 제품에 고유하지는 않지만 제품과 3 개의 경쟁 제품에 고유 한 것일 수 있습니다. 기존 솔루션을 배제하는 이상한 요구 사항이있을 수 있습니다. 기술적 인 이유로 기존 솔루션으로는 문제를 해결하지 못할 수 있습니다 (예 : 성능 목표를 달성하지 못함-이것이 게임 개발에서 구조화 된 기본 데이터를 재창조하는 일반적인 이유 임).

우리에게는 인프라, 라이브러리 코드 및 스캐 폴딩이 대부분 다른 팀이나 타사에서 유지 관리되므로 (보일러 플레이트는 모든 곳에서 고르게 분산되어 있지만) UI / 비즈니스 로직을 수행하는 팀에있는 것처럼 간단 할 수 있습니다.
Ixrec

8
$ 50 이상을 주문하면 무료 치즈 버팀대가 제공됩니다.
kdgregory

1
@ raptortech97 그는 "50 달러 이상을 주문하면 무료 치즈를 넣은 막대기를 얻는다"는 것이 비즈니스 논리라고 말합니다.
user253751 2019 년

"비즈니스 규칙 중 하나가 기본적으로 미국 정부 채권 가격을 32 번째 표기법으로 표시하는 경우 (사용자가이를 구성 할 수있는 UI를 제공하는 경우), 프리젠 테이션 로직은이 규칙이 존재한다는 사실을 최소한 알아야합니다." '하지 말아야 할 사람도 있습니다. UI에는 비즈니스 로직 (또는 아마도 모델이지만 ...)에 전달 된 문자열을 표시하기 위해 레이블 / 텍스트 상자 / 위젯이 있어야 할 수도 있습니다.
Joshua Drake

답변:


27

게임이나 그래픽 집약적 인 응용 프로그램에 대한 경험이 많지 않기 때문에 CRUD 응용 프로그램 에 대한 몇 가지 팁을 제공합니다 .

  • 비즈니스 로직에는 일반적으로 비즈니스 소유자가 수년간의 운영에 대해 배우 거나 결정한 규칙이 포함됩니다 ( 예 : "고객이 아직 마지막 지불을 아직 완료하지 않은 경우 새 크레딧 거부" 또는 "아침 식사를 판매하지 않음) 지난 오전 11시 " 또는 "월요일과 화요일에는 고객이 1 개의 가격으로 두 개의 피자를 구입할 수 있습니다 " .
  • 물론 프리젠 테이션 레이어는 할인 가능 여부 또는 크레딧이 거부 된 이유를 나타내는 메시지를 보여 주어야하지만, 이러한 레이어는 그러한 것들을 결정하지 않고 단지 사용자에게만 전달되는 것입니다.
  • 비즈니스 로직에는 일반적으로 워크 플로가 포함됩니다. 예를 들어 "고객이 필수 문서를 제출하지 않은 경우이 항목은 일부 관리자가 3 일 (근무일 기준) 이내에 증명하거나 '정보 요청'단계에 배치해야합니다." .
  • 프레젠테이션 계층은 일반적으로 이러한 종류의 워크 플로를 처리하지 않으며 워크 플로의 상태 만 반영합니다.
  • 또한 비즈니스 로직에 의해 이미 결정이 내려 졌기 때문에 데이터 액세스 계층은 일반적으로 간단합니다. 이 계층은 예를 들어 MS SQL Server에서 Oracle로 데이터를 마이그레이션하기로 결정할 때 영향을받습니다.
  • GUI가 서버에 대한 호출을 피하기 위해 일부 유효성 검사를 수행하는 것이 사실이지만, 이는 신중하게 수행해야하거나 해당 계층에 많은 비즈니스 논리가있을 수 있습니다.
  • 응용 프로그램에서 걱정할 사항이 없으며 프레젠테이션 계층에 너무 많은 비즈니스 논리가 있다는 사실 때문에 많은 혼란이 생길 ​​수 있습니다. 애플리케이션 계층 또는 데이터 액세스 계층에 비즈니스 로직이 잘못되었다는 사실이 비즈니스 로직이라는 사실을 바꾸지는 않습니다.
  • 마일 / 야드 / 피트 대신 미터법으로 거리를 표시하는 것과 같은 것은 프리젠 테이션 로직이 아니라 비즈니스 로직 입니다. 비즈니스 계층은 필요한 단위로 데이터를 반환하고 프리젠 테이션 계층에 적절한 레이블을 표시하기 위해 처리중인 단위를 알려 주어야하지만 비즈니스 논리와 관련이 있습니다.
  • 비즈니스 로직은 Postgres 대신 Oracle을 사용하고 있다는 사실이나 회사가 로고나 스타일 시트를 변경 한 사실에 영향을받지 않아야합니다 .
  • 비즈니스 규칙 은 앱을 작성하여 자동화하는지 여부에 관계없이 존재합니다 . 펜과 종이 같은 첨단 기술 솔루션을 사용하는 경우에도 적용 할 수 있습니다.
  • 모바일 버전의 데스크톱 앱 또는 웹 버전이있는 경우 각 버전 마다 서로 다른 프레젠테이션 계층 이 있지만 동일한 비즈니스 계층이 있습니다.

5

대부분의 작업이 UI 계층에있는 것처럼 들립니다. 비즈니스상의 이유로 표시 형식을 변경한다고해서 비즈니스 논리가 암시되지는 않습니다. 변경은 뷰 로직에 대한 변경입니다.

형식을 변경할 수 있다는 것은 기본 설정의 지속성을 포함하는 일부 비즈니스 논리를 의미합니다.

쿠키에 형식을 유지하는 것도 뷰 레이어에서 구현 될 수 있습니다.

그러나 이것은 MVC 방식으로 구현 될 수 있습니다. (일부 모델은 기본 설정을 처리 할 수있는 자체 MVC로보기를 구현합니다.)

  • 사용자 선호도는 모델 (데이터베이스 / 쿠키)로 저장할 수 있습니다.
  • 컨트롤러는 모델에서 사용자의 기본 설정을 변경하여 형식 요청에 반응합니다.
  • 보기는 사용자의 환경 설정에 따라 조정됩니다. 선호도는 모델에서 요청하거나 컨트롤러가 제공 할 수 있습니다.

응용 프로그램에 대한 교육적인 추측.

  • 사용 가능한 채권 및 가격 데이터가 포함 된 모델이 있습니다.
  • 채권 검색, 가격 표시, 수율 비교, 주문 받기 및 요청에 대한 비즈니스 모델이 반환 한 결과 표시 등 사용자가 수행 할 수있는 다양한 작업을 볼 수 있습니다.
  • 비즈니스 로직은 다음과 같은 것을 처리합니다.

    • 검색을 수행하고보기를 표시합니다.
    • 채권 가격을 찾고 조회 표시를 제공합니다.
    • 수율을 비교하고보기에 표시 할 데이터를 제공합니다.
    • 주문을 처리하고 모델에 저장합니다.

이 작업을 올바르게 수행하면 모델이나 비즈니스 로직을 변경하지 않고도 여러보기 구성 요소를 제공 할 수 있습니다. 예를 들어 현재 디자인이 웹 사이트 인 경우 iPhone 또는 Android 응용 프로그램의 새 뷰 서버는 기존 모델 및 비즈니스 논리를 사용합니다. 주문이 이행 될 때 푸시 알림을 제공하는 새로운 비즈니스 기능이 도입 될 수 있으며 이로 인해 여러 계층을 변경해야 할 수 있습니다.

이 분류를 통해 우려를 분리 할 수 ​​있습니다.

  • 모델이 나타내는 데이터 레이어는 비교적 안정적인 경향이 있습니다.
  • 비즈니스 계층은 비즈니스 의사 결정이 적용되는 위치입니다. 요청이 이행 될 수 있습니까? 필요한 모든 데이터를 얻었습니까? 사용자가 승인 되었습니까? 거래에 적신호가 있습니까?
  • 뷰 층은 덜 안정된 경향이 있고, 둘 이상이있을 수있다. 응용 프로그램의 모양과 느낌이 상주합니다. 다른 레이어를 변경하지 않고도 응용 프로그램을 완전히 다시 스키닝 할 수 있습니다.
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.