วิธีปฏิบัติที่ดีที่สุดหรือรูปแบบการออกแบบสำหรับการดึงข้อมูลสำหรับการรายงานและแดชบอร์ดในแอปพลิเคชันที่มีโดเมนมากมาย

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

จากประสบการณ์ของฉันมีแอพพลิเคชั่นสองด้าน - ด้าน "งาน" ซึ่งส่วนใหญ่ขับเคลื่อนด้วยโดเมนและเป็นที่ที่ผู้ใช้โต้ตอบอย่างล้นหลามกับโมเดลโดเมน ("เอ็นจิ้น" ของแอปพลิเคชัน) และด้านการรายงาน รับข้อมูลตามสิ่งที่เกิดขึ้นในงาน

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

แล้วด้านรายงานล่ะ คลังข้อมูลยอมรับได้หรือไม่หรือมีการออกแบบที่ไม่ดีเพราะรวมตรรกะทางธุรกิจไว้ในฐานข้อมูลและข้อมูลเอง ในการรวบรวมข้อมูลจากฐานข้อมูลลงในข้อมูลคลังข้อมูลคุณต้องใช้ตรรกะทางธุรกิจและกฎกับข้อมูลและตรรกะและกฎนั้นไม่ได้มาจากรูปแบบโดเมนของคุณมาจากกระบวนการรวบรวมข้อมูลของคุณ มันผิดหรือเปล่า?

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

ตัวอย่างเช่นสมมติว่ารายงาน / แดชบอร์ดจำเป็นต้องแสดงรายการของโครงการที่ใช้งานอยู่ (จินตนาการ 10,000 โครงการ) แต่ละโครงการจะต้องมีชุดของตัวชี้วัดที่แสดงพร้อมตัวอย่างเช่น:

1. งบประมาณรวม
2. ความพยายามในวันที่
3. อัตราการเผาไหม้
4. วันหมดงบประมาณที่อัตราการเขียนปัจจุบัน
5. เป็นต้น

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

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

ดูเหมือนว่าในกรณีเหล่านี้ว่า SQL นั้นดีในการ crunching data และทำไมไม่ใช้มัน? แต่คุณมีเหตุผลทางธุรกิจนอกโมเดลโดเมนของคุณ การเปลี่ยนแปลงใด ๆ กับตรรกะทางธุรกิจจะต้องมีการเปลี่ยนแปลงในรูปแบบโดเมนของคุณและแผนการรวมการรายงานของคุณ

ฉันสูญเสียวิธีการออกแบบส่วนการรายงาน / แดชบอร์ดของแอปพลิเคชันใด ๆ ที่เกี่ยวกับการออกแบบที่ขับเคลื่อนด้วยโดเมนและแนวปฏิบัติที่ดี

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

ฉันกำลังมองหาความช่วยเหลือใด ๆ ในบริเวณนี้ - หนังสือ, รูปแบบการออกแบบ, คำสำคัญสำหรับ google, บทความ, อะไรก็ได้ ฉันไม่พบข้อมูลใด ๆ ในหัวข้อนี้

แก้ไขและตัวอย่างอื่น

อีกตัวอย่างที่สมบูรณ์แบบที่ฉันเจอในวันนี้ ลูกค้าต้องการรายงานสำหรับทีมขายลูกค้า พวกเขาต้องการสิ่งที่ดูเหมือนเป็นเมตริกง่ายๆ:

สำหรับพนักงานขายแต่ละคนยอดขายประจำปีของพวกเขาจนถึงปัจจุบันเป็นเท่าใด

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

รับทั้งหมดSalesPeople->
สำหรับแต่ละคนจะได้รับSalesOpportunities->
สำหรับแต่ละคนจะได้รับเปอร์เซ็นต์ของยอดขายและคำนวณยอดขายของพวกเขา
จากนั้นเพิ่มSalesOpportunityยอดขาย ทั้งหมดของพวกเขา

และนั่นคือหนึ่งตัวชี้วัด หรือคุณสามารถเขียนแบบสอบถาม SQL ซึ่งสามารถทำได้อย่างรวดเร็วและมีประสิทธิภาพและปรับแต่งให้รวดเร็ว

แก้ไข 2 - รูปแบบ CQRS

ฉันได้อ่านเกี่ยวกับรูปแบบของ CQRSและในขณะที่น่าสนใจแม้แต่มาร์ตินฟาวเลอร์ก็บอกว่ามันไม่ผ่านการทดสอบ ดังนั้นปัญหานี้ได้รับการแก้ไขในอดีตอย่างไร ทุกคนต้องเผชิญกับปัญหานี้ในบางจุดหรืออย่างอื่น อะไรคือวิธีการที่ได้รับการยอมรับหรือเป็นที่นิยมด้วยประวัติความสำเร็จ?

แก้ไข 3 - ระบบการรายงาน / เครื่องมือ

อีกสิ่งที่ควรพิจารณาในบริบทนี้คือเครื่องมือการรายงาน Reporting Services / Crystal Reports, Analysis Services และ Cognoscenti ฯลฯ ทั้งหมดคาดหวังข้อมูลจาก SQL / ฐานข้อมูล ฉันสงสัยว่าข้อมูลของคุณจะเข้ามาในธุรกิจของคุณในภายหลัง และพวกเขาและคนอื่น ๆ เช่นพวกเขาเป็นส่วนสำคัญของการรายงานในระบบขนาดใหญ่จำนวนมาก ข้อมูลสำหรับสิ่งเหล่านี้ได้รับการจัดการอย่างเหมาะสมอย่างไรที่มีแม้แต่ตรรกะทางธุรกิจในแหล่งข้อมูลสำหรับระบบเหล่านี้และในรายงานของตัวเอง?

นี่คือคำตอบที่กะล่อนมาก แต่การได้รับสิทธิในหัวใจของเรื่อง:

ในแง่ของ DDD อาจคิดว่าการรายงานเป็นบริบทที่มีขอบเขตหรือไม่ดังนั้นแทนที่จะคิดในแง่ของรูปแบบโดเมน "THE" คุณควรยินดีที่จะคิดว่ามันโอเคที่จะมีมากกว่าหนึ่งแบบ ดังนั้นใช่มันก็ไม่เป็นไรหากโดเมนการรายงานมีการรายงานตรรกะทางธุรกิจในโดเมนนั้นเช่นเดียวกับที่มันโอเคที่โดเมนการทำธุรกรรมจะมีตรรกะทางธุรกิจในการทำธุรกรรม

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

เนื่องจากฉันเห็นว่าคุณได้เพิ่มความโปรดปรานให้กับคำถามฉันจึงอ่านคำถามอีกครั้งและสังเกตว่าคุณกำลังขอทรัพยากรที่เฉพาะเจาะจงเกี่ยวกับเรื่องนี้ดังนั้นฉันคิดว่าฉันเริ่มต้นด้วยการแนะนำให้คุณดูคำถามกองซ้อนล้นอื่น ๆ ในเรื่องนี้ และฉันพบหนึ่งhttps://stackoverflow.com/questions/11554231/how-does-domain-driven-design-handle-reporting

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

ฉันยังพบhttp://www.martinfowler.com/bliki/ReportingDatabase.htmlซึ่งฉันพบลิงค์จากที่นี่: http://groups.yahoo.com/neo/groups/domaindrivendesign/conversations/topics/2261

นี่เป็นบทความที่น่าสนใจจาก ACM ในเรื่อง: http://dl.acm.org/citation.cfm?id=2064685 แต่อยู่หลัง paywall ดังนั้นฉันจึงไม่สามารถอ่านได้จริง ๆ (ไม่ใช่สมาชิก ACM :()

นอกจากนี้ยังมีคำตอบที่นี่สำหรับคำถามที่คล้ายกัน: https://stackoverflow.com/questions/3380431/cqrs-ddd-synching-reporting-database

และอันนี้: http://snape.me/2013/05/03/applying-domain-driven-design-to-data-warehouses/

หวังว่านี่จะช่วยได้!

ความเข้าใจของฉันจากคำถามของคุณคือ: การสมัครงานประจำวันมี

View >> คอนโทรลเลอร์ >> รุ่น (BL) >> ฐานข้อมูล (Data)

แอพลิเคชันเพื่อการรายงาน

มุมมอง >> คอนโทรลเลอร์ >> โมเดล >> ฐานข้อมูล (Data + BL)

ดังนั้นการเปลี่ยน BL สำหรับ ' แอปพลิเคชันงาน ' จะนำไปสู่การเปลี่ยนแปลงใน ' การรายงาน ' BL ด้วย นั่นคือปัญหาที่แท้จริงของคุณใช่ไหม ก็โอเคที่จะทำการเปลี่ยนแปลงสองครั้งความเจ็บปวดที่คุณต้องทำต่อไป เหตุผลก็คือทั้ง BLs แยกจากกันด้วยความกังวลของพวกเขา หนึ่งสำหรับการดึงข้อมูลและอีกหนึ่งสำหรับ aggregrating ข้อมูล นอกจากนี้ BL ดั้งเดิมของคุณและการทำให้รุนแรงขึ้น BL จะถูกเขียนในเทคโนโลยีหรือภาษาที่แตกต่างกัน ( C # / java และ SQL proc ) ไม่มีทางหนีรอดไปได้

ให้อีกตัวอย่างหนึ่งที่ไม่เกี่ยวข้องกับการรายงานโดยเฉพาะ สมมติว่า บริษัท XXX ติดตามอีเมลของผู้ใช้ทั้งหมดเพื่อการตีความและขายข้อมูลนั้นให้กับ บริษัท การตลาด ตอนนี้มันจะมีหนึ่ง BL สำหรับการตีความและอีกหนึ่ง BL สำหรับ aggregrating ข้อมูลสำหรับ บริษัท การตลาด ข้อกังวลต่างกันสำหรับ BLs พรุ่งนี้ถ้า BL ของพวกเขาเปลี่ยนแปลงเช่นว่าอีเมลที่มาจากคิวบาควรถูกละเว้นตรรกะทางธุรกิจจะเปลี่ยนไปทั้งสองข้าง

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

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

คุณอาจแบ่งเป็นสองปัญหาหลักที่คุณกำลังแก้ไข:

1. การรวมหรือข้อมูลคลังสินค้า สิ่งนี้ควรประมวลผลแหล่งข้อมูลบางส่วนและรวมข้อมูลในลักษณะที่เก็บไว้ในแหล่งข้อมูลอื่น

2. การค้นหาแหล่งข้อมูลที่รวบรวมเพื่อจัดทำระบบธุรกิจอัจฉริยะ

ไม่มีปัญหาเหล่านี้อ้างอิงฐานข้อมูลหรือเอ็นจินการเก็บข้อมูลเฉพาะใด ๆ เลเยอร์โดเมนของคุณควรติดต่อกับอินเทอร์เฟซที่ติดตั้งในเลเยอร์โครงสร้างพื้นฐานโดยอะแดปเตอร์หน่วยเก็บข้อมูลต่างๆ

คุณอาจมีคนงานหลายคนหรือทำงานตามกำหนดเวลาบางส่วนซึ่งแบ่งออกเป็นส่วนที่เคลื่อนไหวไม่กี่:

• สิ่งที่จะสอบถาม
• สิ่งที่จะรวม
• บางสิ่งบางอย่างในการจัดเก็บ

หวังว่าคุณจะเห็น CQRS เปล่งประกายผ่านทางนั้น

ในด้านการรายงานควรทำแบบสอบถามเท่านั้น แต่ไม่ต้องลงในฐานข้อมูลโดยตรง ผ่านอินเทอร์เฟซของคุณและผ่านเลเยอร์โดเมนของคุณที่นี่ นี่ไม่ใช่โดเมนปัญหาเดียวกับงานหลักของคุณ แต่ควรมีตรรกะบางอย่างที่นี่ที่คุณต้องการปฏิบัติตาม

ทันทีที่คุณดำดิ่งลงสู่ฐานข้อมูลโดยตรงคุณจะต้องพึ่งพามันมากขึ้นและในที่สุดอาจรบกวนความต้องการข้อมูลแอปพลิเคชันเดิมของคุณ

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

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

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

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

เป็นเรื่องปกติที่จะแยกที่เก็บข้อมูลด้านปฏิบัติการ / ธุรกรรมออกจากการรายงาน หลังอาจมีข้อกำหนดในการเก็บข้อมูลด้วยเหตุผลทางกฎหมาย (เช่นข้อมูลทางการเงินเจ็ดปีสำหรับการตรวจสอบทางการเงิน) และคุณไม่ต้องการทั้งหมดในแหล่งข้อมูลธุรกรรมของคุณ

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

ฉันจะไม่แนะนำการรายงานกับที่เก็บข้อมูลธุรกรรมของคุณ

หากคุณต้องการกดต่อไปนี้เป็นความคิดเพิ่มเติม:

1. "ดีที่สุด" เป็นเรื่องส่วนตัวและใช้งานได้ดี
2. ฉันจะซื้อผลิตภัณฑ์รายงานแทนที่จะเขียนด้วยตนเอง
3. หากคุณใช้ฐานข้อมูลเชิงสัมพันธ์ SQL เป็นเกมเดียวในเมือง
4. ขั้นตอนการจัดเก็บขึ้นอยู่กับว่าคุณมีทักษะในการเขียน

ซอฟต์แวร์การจัดการโครงการที่คุณใช้อยู่ในบ้าน? ฉันจะซื้อก่อนสร้าง บางอย่างเช่น Rally และ Microsoft Project

ก่อนอื่นคำศัพท์บางคำสิ่งที่คุณเรียกว่า task task เรียกว่า Transactional และด้านการรายงานคือ Analytics

คุณได้พูดถึง CQRS แล้วซึ่งเป็นวิธีการที่ยอดเยี่ยม แต่มีการประยุกต์ใช้วิธีปฏิบัติที่เป็นเอกสารเล็กน้อย

สิ่งที่ได้รับการทดสอบอย่างหนักคือการเสริมการประมวลผลธุรกรรมของคุณด้วยเครื่องมือประมวลผลการวิเคราะห์ บางครั้งเรียกว่าคลังข้อมูลหรือ Data Cubes gotcha ที่ใหญ่ที่สุดสำหรับการวิเคราะห์คือการพยายามเรียกใช้คิวรีกับข้อมูลธุรกรรมของคุณแบบเรียลไทม์นั้นไม่มีประสิทธิภาพที่ดีที่สุดเพราะเป็นไปได้ที่จะเพิ่มประสิทธิภาพฐานข้อมูลสำหรับการอ่านหรือการเขียนเท่านั้น สำหรับธุรกรรมคุณต้องการความเร็วในการเขียนสูงเพื่อหลีกเลี่ยงความล่าช้าในการประมวลผล / ทำสิ่งต่าง ๆ สำหรับการรายงานคุณต้องการความเร็วในการอ่านสูงเพื่อให้สามารถทำการตัดสินใจได้

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

หนังสือยอดเยี่ยมสำหรับเร่งความเร็วในการจัดเก็บข้อมูลคือชุดเครื่องมือ Data Warehouseโดย Ralph Kimball สำหรับแนวทางเพิ่มเติม ดาวน์โหลดชุดทดลองของ SQL Server และหยิบชุดเครื่องมือคลังข้อมูลของ Microsoftซึ่งใช้สำหรับการอภิปรายทั่วไปของหนังสือเล่มแรก แต่แสดงวิธีการใช้แนวคิดโดยใช้ SQL Server

มีหนังสือที่เชื่อมโยงหลายเล่มจากหน้าเว็บเหล่านั้นซึ่งมีรายละเอียดเพิ่มเติมเกี่ยวกับ ETL, การออกแบบสตาร์สคี, BI, แดชบอร์ดและหัวข้ออื่น ๆ ที่จะช่วยให้คุณดำเนินการต่อไปได้

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

แล้วด้านรายงานล่ะ คลังข้อมูลยอมรับได้หรือไม่หรือมีการออกแบบที่ไม่ดีเพราะรวมตรรกะทางธุรกิจไว้ในฐานข้อมูลและข้อมูลเอง

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

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

เพื่อปรับปรุงประสิทธิภาพการสืบค้นคุณสามารถใช้มุมมองที่ปรากฏขึ้น เมื่อมีการดำเนินการกับโมเดลของคุณ (เช่นจองเวลา 4 ชั่วโมงของบุคคลนี้เพื่อโปรเจ็กต์ x) และประสบความสำเร็จสามารถสร้างเหตุการณ์ที่คุณสามารถเก็บไว้ในฐานข้อมูลการรายงานและทำการคำนวณที่จำเป็นสำหรับรายงานของคุณ จากนั้นจะสามารถสืบค้นได้อย่างรวดเร็ว

ทำให้ธุรกรรมและบริบทการรายงานของคุณแยกจากกันฐานข้อมูลเชิงสัมพันธ์ถูกสร้างขึ้นสำหรับการรายงานรูปแบบโดเมนไม่ใช่

แก้ไข

บล็อกโพสต์ที่มีประโยชน์ในเรื่องhttp://se-thinking.blogspot.se/2012/08/how-to-handle-reporting-with-domain.htmlหัวข้อ

4 ปีต่อมาและฉันเพิ่งพบคำถามนี้อีกครั้งและฉันมีคำตอบให้ฉัน

ขึ้นอยู่กับแอปพลิเคชันของคุณและเป็นความต้องการเฉพาะฐานข้อมูลโดเมน / ธุรกรรมของคุณและการรายงานของคุณอาจเป็น "ระบบ" หรือ "เครื่องมือ" แยกต่างหากหรือสามารถให้บริการได้ด้วยระบบเดียว อย่างไรก็ตามควรแยกกันอย่างมีเหตุผล - ซึ่งหมายความว่าพวกเขาใช้วิธีการที่แตกต่างกันในการดึงและให้ข้อมูลกับ UI

ฉันต้องการให้พวกเขาแยกทางกายภาพ (นอกเหนือจากการแยกทางตรรกะ) แต่หลายครั้งที่คุณเริ่มต้นพวกเขาออกมาด้วยกัน (ร่างกาย) และจากนั้นเมื่อแอปพลิเคชันเติบโตขึ้นคุณแยกพวกเขาออก

ไม่ว่าจะด้วยวิธีใดพวกเขาควรมีเหตุผลที่แตกต่างกัน การทำสำเนาตรรกะทางธุรกิจในระบบการรายงานเป็นเรื่องปกติ สิ่งสำคัญคือระบบการรายงานจะได้คำตอบเดียวกับระบบโดเมน - แต่โอกาสที่มันจะไปถึงที่นั่นด้วยวิธีที่ต่างกัน ตัวอย่างเช่นระบบโดเมนของคุณจะมีกฎเกณฑ์ทางธุรกิจที่เข้มงวดจำนวนมากถูกนำมาใช้ในรหัสขั้นตอน (น่าจะเป็น) ระบบการรายงานสามารถใช้กฎเดียวกันนี้เมื่ออ่านข้อมูล แต่จะทำเช่นนั้นผ่านรหัสที่ใช้ SET (เช่น SQL)

นี่คือสิ่งที่วิวัฒนาการของสถาปัตยกรรมแอปพลิเคชันของคุณอาจมีลักษณะเหมือนจริงตามที่วิวัฒนาการ:

ระดับ 1 - โดเมนและระบบการรายงานที่แยกกันอย่างมีเหตุผล แต่ยังอยู่ใน codebase และฐานข้อมูลเดียวกัน

ระดับ 2 - โดเมนที่แยกจากกันอย่างมีเหตุผลและระบบการรายงาน แต่แยกฐานข้อมูลทันทีด้วยการซิงค์

ระดับ 3 - โดเมนและระบบการรายงานทางตรรกะและทางกายภาพแยกและฐานข้อมูลแยกต่างหากด้วยการซิงค์

แนวคิดหลักคือการรายงานและโดเมนมีความต้องการที่แตกต่างกันอย่างสิ้นเชิง โปรไฟล์ข้อมูลที่แตกต่างกัน (อ่าน vs เขียนและอัปเดตความถี่), ข้อกำหนดด้านประสิทธิภาพที่แตกต่างกัน ฯลฯ ดังนั้นพวกเขาจำเป็นต้องนำไปปฏิบัติต่างกันและจำเป็นต้องทำซ้ำตรรกะทางธุรกิจ

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

ต้องการรายงาน / แดชบอร์ดเพื่อแสดงรายการโครงการที่ใช้งานอยู่

สถานะของแต่ละโครงการควรจัดเก็บเป็นข้อมูลคงที่การคำนวณต่อข้อมูลและการจัดรูปแบบที่ดีในฐานข้อมูลและการจำลองใด ๆ ที่ควรได้รับการจัดการบนไคลเอนต์เป็น WebApp

วันหมดงบประมาณที่อัตราการเขียนปัจจุบัน

การฉายภาพประเภทนี้ไม่ควรทำงานตามความต้องการ การจัดการข้อมูลนี้เมื่อมีการร้องขอเช่นทำการคำนวณเกี่ยวกับทรัพยากรอัตรางานเหตุการณ์สำคัญ ฯลฯ จะส่งผลให้มีการใช้เลเยอร์การคำนวณอย่างกว้างขวางโดยไม่ต้องใช้ผลลัพธ์เหล่านี้ซ้ำสำหรับการโทรในอนาคต

จินตนาการถึงสภาพแวดล้อมแบบกระจาย ( คลาวด์ส่วนตัวหรือสาธารณะ ) คุณจะได้รับค่าใช้จ่ายมหาศาลในชั้นของการคำนวณการใช้ฐานข้อมูลต่ำและการขาดแคชโดยรวม

ควรดำเนินการผ่านโดเมนก่อนหรือไม่ แล้วประสิทธิภาพล่ะ

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

ดังนั้นการค้นหาครั้งแรกก่อนที่จะจบสถาปัตยกรรมซอฟต์แวร์ก็สามารถนำระบบแคชกระจาย

(คำขอ: การรวม)! = 1: 1

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

กระจายการคำนวณบนไคลเอนต์

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

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

ข้อสรุปของฉันคือ:

1. ทำความเข้าใจว่าจำเป็นต้องใช้การทำงานจำนวนเท่าใดเพื่อดำเนินการนำเสนอข้อมูล

2. วิเคราะห์จำนวนของสิ่งเหล่านี้สามารถทำได้ในพื้นหลัง (แล้วกระจายผ่านระบบแคชหลังจากการทำให้ปกติของพวกเขา);

3. ทำความเข้าใจกับจำนวนการดำเนินการที่สามารถดำเนินการในไคลเอนต์, รับการกำหนดค่าของโครงการ, เรียกใช้บน Views บน WebApp และลดการคำนวณที่ดำเนินการในแบ็คเอนด์

ใช้แคชสำหรับการสืบค้นใช้โดเมนสำหรับการแคช

มีคุณสมบัติที่เรียกว่า "ผู้ใช้สูงสุด" ใน stackoverflow คุณอาจพบบรรทัดที่ด้านล่างของหน้าผู้ใช้ชั้นนำกล่าวว่า "มีเพียงคำถามและคำตอบที่ไม่ใช่ชุมชนวิกิเท่านั้นที่รวมอยู่ในยอดรวมเหล่านี้ ( อัพเดททุกวัน )" สิ่งนี้บ่งชี้ว่าข้อมูลถูกแคช

แต่ทำไม

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

อย่างไร?

ฉันไม่รู้จริงๆว่าพวกเขาทำเช่นไรดังนั้นนี่เป็นเพียงการเดา :)

อันดับแรกเราต้องค้นหาคำถาม / คำตอบเป้าหมาย ภารกิจการตั้งเวลาสามารถทำงานได้เพียงดึงเป้าหมายที่เป็นไปได้ทั้งหมด

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

ตอนนี้เรามีแคชแล้วมันคือผลลัพธ์ของการสืบทอดโดเมน การสืบค้นนั้นรวดเร็วและง่ายดายเนื่องจากมีเพียงเกณฑ์แบบง่ายที่จะใช้

เกิดอะไรขึ้นถ้าผลลัพธ์ต้องมี "เวลาจริง" มากกว่านี้

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

จำเป็นต้องมี CQRS หรือไม่?

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

บางคำถามที่เกี่ยวข้อง:
1. https://stackoverflow.com/questions/21152958/how-to-handle-summary-report-in-cqrs 2. https://stackoverflow.com/questions/19414951/how-to-use อุดมไปด้วยโดเมนที่มีการดำเนินงานขนาดใหญ่ / 19416703 # 19416703

หวังว่าจะช่วย :)

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

ตอนนี้ฉันได้อธิบายอย่างชัดเจนแล้วนี่คือสิ่งที่ฉันคิดไว้ - ฉันจะใช้ตัวอย่างแรกของคุณ(ตัวชี้วัดโครงการ)เพื่ออธิบาย:

เมื่อมีคนแก้ไขโครงการคุณกำลังโหลดและบันทึกผ่านโมเดลโดเมนของคุณ
ในขณะนี้คุณมีข้อมูลทั้งหมดที่โหลดเพื่อคำนวณตัวชี้วัดทั้งหมดของคุณ(งบประมาณรวมความพยายามจนถึงปัจจุบัน ฯลฯ )สำหรับโครงการนี้

คุณสามารถคำนวณสิ่งนี้ในรูปแบบโดเมนและบันทึกลงในฐานข้อมูลด้วยส่วนที่เหลือของรูปแบบโดเมน
ดังนั้นProjectการเรียนในรูปแบบโดเมนของคุณจะมีคุณสมบัติบางอย่างเช่นTotalBudget, EffortToDateฯลฯ และยังจะมีคอลัมน์ที่มีชื่อผู้ที่อยู่ในตารางฐานข้อมูลที่รูปแบบโดเมนของคุณจะถูกเก็บไว้(ในตารางเดียวกันหรือในตารางที่แยกต่างหาก ... doesn 'T เรื่อง)

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

ดังนั้นเมื่อใดก็ตามที่คุณต้องการรายงานชนิดใด ๆ ข้อมูลที่จำเป็นทั้งหมดจะมีอยู่แล้ว(คำนวณล่วงหน้า)และคุณสามารถทำสิ่งนี้ได้:

select ProjectName, TotalBudget, EffortToDate from Projects where TotalBudget > X

ไม่สำคัญว่าคุณจะได้รับข้อมูลโดยตรงจากตารางที่เก็บแบบจำลองโดเมนหรือถ้าคุณดึงข้อมูลไปยังฐานข้อมูลที่สองไปยังคลังข้อมูลหรืออะไรก็ตาม:

1. หากที่เก็บรายงานของคุณแตกต่างจากที่เก็บข้อมูลจริงของคุณคุณสามารถคัดลอกข้อมูลจาก "ตารางโมเดลโดเมน"
2. หากคุณสอบถามที่เก็บข้อมูลจริงของคุณโดยตรงข้อมูลนั้นมีอยู่แล้วและคุณไม่จำเป็นต้องคำนวณอะไรเลย

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