“ ตรรกะทางธุรกิจ” หมายความว่าอย่างไรหากไม่ใช่“ รหัสบุคคลที่ไม่ใช่บุคคลที่สาม”?

ฉันได้ยินคนพูดถึงตรรกะทางธุรกิจมากมายในที่ทำงานและออนไลน์และฉันได้อ่านคำถามหลายข้อเกี่ยวกับเว็บไซต์นี้ แต่คำนี้ยังไม่สมเหตุสมผลสำหรับฉัน ตัวอย่างเช่นต่อไปนี้เป็นคำสั่ง (ถอดความ) ที่ฉันมักจะเห็น:

• "ตรรกะทางธุรกิจเป็นส่วนหนึ่งของโปรแกรมของคุณที่เข้ารหัสกฎเกณฑ์ทางธุรกิจที่แท้จริง" คำจำกัดความส่วนใหญ่ที่ฉันได้อ่านเป็นคำวงกลมเช่นนี้

• "ตรรกะทางธุรกิจคือทุกสิ่งที่ไม่เหมือนใครสำหรับแอปพลิเคชันของคุณโดยเฉพาะ" ฉันไม่เห็นว่าสิ่งนี้แตกต่างจาก "แอปพลิเคชันของคุณโดยเฉพาะคืออะไร แต่เป็นตรรกะทางธุรกิจ" เว้นแต่ว่าเราจะมีการคิดค้นใหม่โดยบังเอิญ ดังนั้นชื่อคำถาม

• "ควรมี Business Logic Layer เหนือ Data Access Layer ของคุณและต่ำกว่า GUI Layer ของคุณ" ในรหัสที่ฉันเขียนตัวเข้าถึงฐานข้อมูลต้องทราบว่าข้อมูลใดที่พวกเขาควรจะเข้าถึงและรหัส UI ต้องรู้มากมายเกี่ยวกับสิ่งที่กำลังแสดงเพื่อแสดงอย่างถูกต้องและไม่มีอะไรทำระหว่าง ทั้งสองแห่งนั้นไม่ใช่การส่งข้อมูลระหว่างไคลเอนต์และเซิร์ฟเวอร์ ดังนั้นสิ่งที่ควรจะเป็น Business Logic Layer?

• "ตรรกะทางธุรกิจควรแยกออกจากตรรกะการนำเสนอ" คำขอคุณสมบัติส่วนใหญ่ที่เราได้รับคือการเปลี่ยนตรรกะการนำเสนอด้วยเหตุผลทางธุรกิจ หากหนึ่งในกฎเกณฑ์ทางธุรกิจคือการแสดงราคาพันธบัตรรัฐบาลสหรัฐฯในรูปแบบที่ 32 โดยค่าเริ่มต้น (ในขณะเดียวกันก็ให้ UI สำหรับผู้ใช้ในการกำหนดค่านั้น) ตรรกะการนำเสนอต้องมีอย่างน้อยต้องรู้ว่ามีกฎนี้อยู่หรือไม่ นอกจากนี้ดูเหมือนว่าส่วนสำคัญของการออกแบบ UX ช่วยให้ผู้ใช้เข้าใจกฎเกณฑ์ทางธุรกิจซอฟต์แวร์ของเราพยายามนำไปใช้

เป็นไปได้หรือไม่ที่ฉันอยู่ในทีมที่ทำแค่ตรรกะทางธุรกิจและตรรกะอื่น ๆ ที่ไม่ใช่ธุรกิจกำลังทำโดยทีมอื่น ๆ ? หรือแนวคิดทั้งหมดของ "ตรรกะทางธุรกิจ" เป็นเอนทิตีแยกต่างหากสามารถใช้งานได้สำหรับแอปพลิเคชันหรือสถาปัตยกรรมบางอย่างเท่านั้น

เพื่อช่วยให้คำตอบที่เป็นรูปธรรม: แกล้งคุณต้องนำแอป Pizza ของ Domino มาใช้อีกครั้ง ตรรกะทางธุรกิจคืออะไรและตรรกะที่ไม่ใช่ธุรกิจของแอพนั้นคืออะไร และเป็นไปได้อย่างไรที่จะวางตรรกะทางธุรกิจที่สั่งพิซซ่าใน "เลเยอร์" ของโค้ดโดยไม่มีข้อมูลพิซซ่าส่วนใหญ่ตกอยู่ในการเข้าถึงข้อมูลและเลเยอร์การนำเสนอ

อัปเดต:ฉันได้ข้อสรุปว่าทีมของฉันอาจใช้รหัส UI 90% และส่วนใหญ่ แต่ไม่ใช่ทั้งหมดที่คุณเรียกว่าตรรกะทางธุรกิจมาจากทีมหรือ บริษัท อื่น ๆ โดยทั่วไปแอปพลิเคชันของเรามีไว้สำหรับตรวจสอบข้อมูลทางการเงินและคุณลักษณะเกือบทั้งหมดเป็นวิธีการที่ผู้ใช้สามารถกำหนดข้อมูลที่พวกเขาเห็นและดูได้อย่างไร ไม่มีการซื้อหรือขายที่เกิดขึ้น (แม้ว่าเราจะรวมเข้ากับแอพอื่น ๆ จาก บริษัท ของเราที่ทำเช่นนั้น) และข้อมูลจริงจะได้รับจากแหล่งข้อมูลภายนอกจำนวนมาก แต่เราอนุญาตให้ผู้ใช้ทำสิ่งต่าง ๆ เช่นส่งสำเนาของ "จอภาพ" ไปยังผู้ใช้รายอื่นดังนั้นรายละเอียดวิธีที่เราจัดการที่อาจมีคุณสมบัติเป็นตรรกะทางธุรกิจ มีแอพมือถือที่ปัจจุบันพูดถึงโค้ดแบ็กเอนด์ของเราอยู่บ้างและฉันรู้ว่าส่วนใดของโค้ดส่วนหน้าของฉันที่ฉันต้องการให้มันแบ่งปันกับ UI ของเราในโลกอุดมคติ (โดยทั่วไป M ใน quasi-MVC ของเรา) ฉันเดาว่านั่นคือ BLL สำหรับเรา

ฉันยอมรับคำตอบของผู้ใช้ 61852 เนื่องจากมันทำให้ฉันเข้าใจอย่างชัดเจนมากขึ้นว่า "ตรรกะทางธุรกิจ" ทำอะไรและไม่ได้อ้างถึง

ฉันจะให้คำแนะนำบางอย่างเกี่ยวกับแอปพลิเคชันCRUDเนื่องจากฉันไม่มีประสบการณ์มากในเกมหรือแอพที่ใช้กราฟิกมาก:

• ตรรกะทางธุรกิจมักจะเกี่ยวข้องกับกฎที่เจ้าของธุรกิจได้เรียนรู้หรือตัดสินใจในช่วงหลายปีของการดำเนินงานเช่น"ปฏิเสธเครดิตใหม่ใด ๆ หากลูกค้ายังไม่ได้ชำระเงินครั้งสุดท้าย"หรือ"เราไม่ขายอาหารเช้า ที่ผ่านมา 11:00"หรือ'จันทร์และวันอังคารที่ลูกค้าสามารถซื้อสองพิซซ่าสำหรับราคาหนึ่ง'
• แน่นอนเลเยอร์การนำเสนอจะต้องแสดงข้อความที่ระบุถึงความพร้อมของส่วนลดหรือเหตุผลของเครดิตที่ถูกปฏิเสธ แต่เลเยอร์ดังกล่าวไม่ได้ตัดสินใจสิ่งเหล่านั้นมันเป็นเพียงการสื่อสารกับผู้ใช้สิ่งที่เกิดขึ้นภายใต้ประทุน
• ตรรกะทางธุรกิจมักจะเกี่ยวข้องกับเวิร์กโฟลว์ตัวอย่างเช่น: "ไอเท็มนี้ต้องได้รับการพิสูจน์ภายใน 3 วันทำการโดยผู้จัดการบางคนหรือใส่ใน 'คำขอข้อมูล' ขั้นตอนหากลูกค้าไม่ได้ส่งเอกสารที่จำเป็นแล้วรายการจะถูกปฏิเสธ" .
• เลเยอร์การนำเสนอมักจะไม่จัดการกับเวิร์กโฟลว์ชนิดนั้น แต่สะท้อนถึงสถานะของเวิร์กโฟลว์เท่านั้น
• นอกจากนี้เลเยอร์การเข้าถึงข้อมูลมักจะตรงไปตรงมาเพราะการตัดสินใจได้ทำโดยตรรกะทางธุรกิจ เลเยอร์นี้ได้รับผลกระทบเมื่อคุณตัดสินใจย้ายข้อมูลจาก MS SQL Server ไปยัง Oracle เป็นต้น
• เป็นจริงบางครั้ง GUI ทำการตรวจสอบความถูกต้องเพื่อหลีกเลี่ยงการโทรไปยังเซิร์ฟเวอร์ แต่นั่นเป็นสิ่งที่ควรทำอย่างรอบคอบหรือคุณอาจมีตรรกะทางธุรกิจจำนวนมากในเลเยอร์นั้น
• ความสับสนส่วนใหญ่ของคุณอาจเกิดขึ้นจากความจริงที่ว่าในใบสมัครของคุณไม่มีข้อกังวลและมีประสิทธิภาพคุณมีตรรกะทางธุรกิจมากเกินไปในชั้นนำเสนอ ความจริงที่ว่าคุณ (ผิด) มีตรรกะทางธุรกิจในชั้นแอปพลิเคชันหรือชั้นการเข้าถึงข้อมูลของคุณไม่ได้เปลี่ยนความจริงที่ว่ามันเป็นตรรกะทางธุรกิจใด ๆ
• สิ่งที่ต้องการแสดงระยะทางในระบบเมตริกแทนไมล์ / หลา / ฟุตไม่ได้นำเสนอตรรกะตรรกะทางธุรกิจของมัน เลเยอร์ธุรกิจจะต้องส่งคืนข้อมูลในหน่วยงานที่ต้องการและบอกเลเยอร์การนำเสนอว่าหน่วยงานใดที่ใช้จัดการเพื่อแสดงเลเบลที่เหมาะสม แต่เป็นปัญหาเชิงตรรกะทางธุรกิจ
• ตรรกะทางธุรกิจไม่ควรได้รับผลกระทบจากความจริงที่ว่าคุณกำลังใช้ Oracle ตอนนี้แทน Postgres หรือจากความจริงที่ บริษัท เปลี่ยนโลโก้หรือสไตล์ชีท
• มีกฎเกณฑ์ทางธุรกิจอยู่หรือไม่ว่าคุณจะทำให้เป็นอัตโนมัติโดยการเขียนแอป สามารถบังคับใช้แม้ว่าธุรกิจจะใช้โซลูชันที่ใช้เทคโนโลยีต่ำเช่นปากกาและกระดาษ
• หากคุณมีเวอร์ชันเดสก์ท็อปสำหรับแอปเดสก์ท็อปหรือเวอร์ชันมือถือแต่ละเวอร์ชันจะมีเลเยอร์การนำเสนอที่แตกต่างกันแต่หวังว่าจะเป็นเลเยอร์ธุรกิจเดียวกัน (หวังว่า)

ดูเหมือนว่างานส่วนใหญ่ของคุณอาจอยู่ในเลเยอร์ UI การเปลี่ยนรูปแบบการแสดงผลด้วยเหตุผลทางธุรกิจไม่ได้หมายถึงตรรกะทางธุรกิจใด ๆ การเปลี่ยนแปลงคือการเปลี่ยนแปลงกับตรรกะมุมมอง

ความสามารถในการเปลี่ยนรูปแบบหมายถึงตรรกะทางธุรกิจบางอย่างที่อาจเกี่ยวข้องกับการคงอยู่ของการตั้งค่า

การคงรูปแบบของคุกกี้ไว้สามารถนำไปใช้ในเลเยอร์มุมมองได้

อย่างไรก็ตามสิ่งนี้สามารถนำมาใช้ในรูปแบบ MVC (บางรุ่นใช้มุมมองเป็น MVC ของตัวเองที่สามารถจัดการกับการตั้งค่า)

• การตั้งค่าของผู้ใช้สามารถจัดเก็บโดยรุ่น (ฐานข้อมูล / คุกกี้)
• ตัวควบคุมจะตอบสนองต่อการร้องขอการจัดรูปแบบโดยการเปลี่ยนการตั้งค่าของผู้ใช้ในรูปแบบ
• มุมมองจะปรับตามความต้องการของผู้ใช้ การตั้งค่าสามารถร้องขอจากรุ่นหรือให้บริการโดยตัวควบคุม

คาดเดาเกี่ยวกับใบสมัครของคุณอย่างมีการศึกษา

• มีรูปแบบที่ประกอบด้วยพันธบัตรที่มีอยู่และข้อมูลการกำหนดราคาสำหรับพวกเขา
• มีมุมมองที่อนุญาตให้ผู้ใช้เห็นสิ่งต่าง ๆ ที่พวกเขาสามารถทำได้: ค้นหาพันธบัตรราคาที่แสดงเปรียบเทียบผลตอบแทนการรับคำสั่งซื้อและแสดงผลลัพธ์ที่ส่งคืนโดยโมเดลธุรกิจเพื่อตอบสนองต่อคำขอ

• ตรรกะทางธุรกิจจัดการสิ่งต่าง ๆ เช่น:

  • ทำการค้นหาและระบุมุมมองที่จะแสดง
  • ค้นหาราคาสำหรับตราสารหนี้และจัดให้มีมุมมองที่จะแสดง
  • การเปรียบเทียบผลผลิตและการให้ข้อมูลสำหรับมุมมองที่จะแสดง
  • ประมวลผลคำสั่งซื้อและจัดเก็บไว้ในรูปแบบ

หากสิ่งนี้ถูกต้องคุณควรจัดเตรียมองค์ประกอบมุมมองหลายรายการโดยไม่เปลี่ยนโมเดลหรือตรรกะทางธุรกิจ ตัวอย่างเช่นหากการออกแบบปัจจุบันเป็นเว็บไซต์เซิร์ฟเวอร์มุมมองใหม่สำหรับแอปพลิเคชัน iPhone หรือ Android จะใช้รูปแบบและตรรกะทางธุรกิจที่มีอยู่ สิ่งเหล่านี้อาจนำเสนอฟังก์ชั่นธุรกิจใหม่เพื่อให้การแจ้งเตือนแบบพุชเมื่อดำเนินการตามคำสั่งซื้อ

การแยกย่อยนี้ช่วยแยกความกังวล

• เลเยอร์ข้อมูลที่แสดงโดยตัวแบบมีแนวโน้มที่จะค่อนข้างเสถียร
• เลเยอร์ธุรกิจเป็นที่ที่การตัดสินใจทางธุรกิจถูกนำไปใช้: คำขอ / สามารถปฏิบัติตามได้หรือไม่? ได้รับข้อมูลที่ต้องการทั้งหมดหรือไม่ ผู้ใช้ได้รับอนุญาตหรือไม่ มีการทำเครื่องหมายสีแดงในธุรกรรมหรือไม่
• เลเยอร์การดูมีความเสถียรน้อยกว่าและอาจมีมากกว่าหนึ่ง นี่คือที่ที่รูปลักษณ์ของแอปพลิเคชันอยู่ เป็นไปได้ที่จะปรับสภาพผิวแอปพลิเคชั่นให้สมบูรณ์โดยไม่ต้องเปลี่ยนเลเยอร์อื่น