คำถามติดแท็ก event-sourcing

ฉันเพิ่งเริ่มดำน้ำใน CQRS / ES เพราะฉันอาจจำเป็นต้องใช้มันในที่ทำงาน ดูเหมือนว่าจะมีแนวโน้มมากในกรณีของเราเพราะมันจะแก้ปัญหาได้มากมาย ฉันร่างความเข้าใจคร่าวๆว่าแอพ ES / CQRS ควรมีลักษณะเป็นบริบทอย่างไรในกรณีการใช้งานธนาคารที่เรียบง่าย (ถอนเงิน) เพื่อสรุปหากบุคคล A ถอนเงิน: ออกคำสั่ง คำสั่งถูกมอบให้สำหรับการตรวจสอบ / การตรวจสอบ เหตุการณ์ถูกส่งไปยังที่เก็บเหตุการณ์หากการตรวจสอบความถูกต้องสำเร็จ ผู้รวบรวมจะ dequeues เหตุการณ์เพื่อใช้การแก้ไขกับการรวม จากสิ่งที่ฉันเข้าใจบันทึกเหตุการณ์เป็นที่มาของความจริงเนื่องจากมันเป็นบันทึกของข้อเท็จจริงเราก็จะสามารถประมาณการภาพใด ๆ ออกมาได้ ตอนนี้สิ่งที่ฉันไม่เข้าใจในสิ่งที่ยิ่งใหญ่นี้คือสิ่งที่เกิดขึ้นในกรณีนี้: กฎ: ยอดคงเหลือต้องไม่ติดลบ person A มียอดคงเหลือ 100e person A ทำการถอนคำสั่งจาก 100e ผ่านการตรวจสอบและ MoneyWithdrewEvent 100e เหตุการณ์ ในระหว่างนี้บุคคล A ออกการถอนคำสั่งอีก 100e MoneyWithdrewEvent ตัวแรกไม่ได้รับการรวบรวม แต่ยังผ่านการตรวจสอบเนื่องจากการตรวจสอบการตรวจสอบกับการรวม (ที่ยังไม่ได้รับการปรับปรุง) MoneyWithdrewEvent …

20 concurrency  cqrs  event-sourcing 

ฉันเจอการออกแบบการจัดหากิจกรรมและฉันต้องการใช้ในแอปพลิเคชันที่ต้องการให้ไคลเอ็นต์ REST (RESTful แม่นยำ) อย่างไรก็ตามฉันล้มเหลวในการเชื่อมต่อสิ่งเหล่านี้เข้าด้วยกันเนื่องจาก REST ค่อนข้างคล้ายกับ CRUD และการจัดหากิจกรรมเป็นงานที่ต้องทำ ฉันสงสัยว่าคุณจะออกแบบการสร้างคำสั่งตามคำขอไปยังเซิร์ฟเวอร์ REST ได้อย่างไร ลองพิจารณาตัวอย่างนี้: ด้วย REST คุณสามารถกำหนดสถานะใหม่ให้กับทรัพยากรที่เรียกว่าไฟล์ ในคำขอเดียวคุณสามารถส่งชื่อไฟล์ใหม่คุณสามารถเปลี่ยนโฟลเดอร์หลักและ / หรือเปลี่ยนเจ้าของไฟล์และอื่น ๆ วิธีสร้างเซิร์ฟเวอร์เพื่อให้ฉันสามารถใช้การจัดหากิจกรรมได้ ฉันคิดถึงความเป็นไปได้เหล่านี้: ตรวจสอบบนเซิร์ฟเวอร์ซึ่งสาขาที่มีการเปลี่ยนแปลงและสร้างคำสั่งที่เหมาะสม ( RenameFileCommand, MoveFileCommand, ChangeOwnerCommand, ... ) และจัดส่งเหล่านี้ที อย่างไรก็ตามในการตั้งค่านี้แต่ละคำสั่งสามารถล้มเหลวในการปล่อยให้ผู้อื่นออกจากการทำธุรกรรมและจากการเปลี่ยนแปลง "atomic" เป็นทรัพยากร ส่งเพียงหนึ่งคำสั่ง ( UpdateFileCommand) และในการจัดการคำสั่งอย่างแม่นยำมากขึ้นในการรวม, ตรวจสอบว่ามีการเปลี่ยนแปลงเขตและส่งแต่ละเหตุการณ์แทน ( FileRenamedEvent, FileMovedEvent, OwnerChangedEvent, ... ) อันนี้ฉันไม่ชอบเลย: ในคำขอไปยังเซิร์ฟเวอร์ฉันจะระบุในส่วนหัวของคำสั่งที่จะใช้เพราะ UI ยังคงเป็นงานที่ใช้ (การสื่อสารจะทำผ่าน REST) …

17 design  rest  event-sourcing 

ฉันกำลังมองหาวิธีในการออกแบบแอพพลิเคชั่น ddd ด้วยระเบียบการตั้งค่า สมมติว่า "ลูกค้า" โดยรวมมีคำสั่งที่กำหนดไว้ว่า "FillProfile" มันจะยกเหตุการณ์ "ProfileFilled" อย่างมีเหตุผล มีกรณีที่คำสั่งจะเพิ่มมากกว่าเหตุการณ์หรือคำสั่งที่จะเพิ่มเหตุการณ์ที่แตกต่างกันตามตรรกะบางอย่าง? หรือนี่คือความสัมพันธ์แบบ 1 - 1 เสมอ (คำสั่ง 1 จะไม่มีการเพิ่มหรือเป็นเหตุการณ์ประเภทที่กำหนดไว้เสมอ) ฉันถามสิ่งนี้เพราะถ้านี่เป็นความจริงที่ว่าคำสั่งจะเพิ่มเหตุการณ์เดียวกันฉันสามารถสร้างระบบการประชุมของฉันในความเป็นจริงนั้น ฉันรู้ว่า "RaiseEvent" จะส่งผลให้ "EventRaised" ...

17 domain-driven-design  cqrs  event-sourcing 

ไวยากรณ์ 3 ของ protobuf ทำให้ฟิลด์ทั้งหมดเป็นตัวเลือกที่ทิ้งคำหลักrequiredและoptionalจากไวยากรณ์ proto2 ก่อนหน้า อ่านความคิดเห็นจากนักพัฒนาดูเหมือนว่ามันทำเพื่อเพิ่มความเข้ากันได้ไบนารีไปข้างหน้า / ถอยหลัง แต่สำหรับฉันนั้นสามารถบังคับใช้ได้โดยเพียงแค่กำหนดชื่อแพคเกจพูดcom.example.messages.v1แล้วปล่อยให้ลูกค้าใช้ deserializers ที่พวกเขาเข้าใจ ในขณะเดียวกันก็ลบสัญญาบางฉบับที่ระบุว่าเป็นประเภทที่มีประโยชน์จากมุมมองด้านวิศวกรรมซอฟต์แวร์ เช่นถ้าฉันมี message Location { double latitude = 1; double longitude = 2; } ใน proto3 เป็นไปได้ที่จะสร้างการสำรองข้อมูลครึ่งหนึ่ง แต่ใช้ได้อย่างสมบูรณ์แบบLocationโดยไม่ได้ให้ข้อมูลหนึ่งในฟิลด์ที่จำเป็น นี่เป็นข้อเสียเปรียบครั้งใหญ่เมื่อสร้างรูปแบบการทำให้เป็นอนุกรมตามสคีมาสำหรับการแลกเปลี่ยนข้อมูลระหว่างลูกค้าหรือไม่ การย้ายรหัสตรวจสอบพิเศษเพิ่มเติมไปยังไคลเอนต์แต่ละรายไม่ได้แย่ไปกว่าการตรวจสอบว่าฟิลด์ที่จำเป็นทั้งหมดมีค่าที่ถูกต้องหรือไม่

15 event-programming  event-sourcing  protobuf 

ฉันรู้ว่าคำถามข้างต้นอาจทำให้เกิดอะไรขึ้นบ้าง แต่ขอให้ฉันพยายามอธิบาย: ฉันกำลังพยายามสรุปแนวคิดที่เกี่ยวข้องสองอย่างโดยทั่วไปแล้วรูปแบบ Saga ( http://www.rgoarchitects.com/Files/SOAPatterns/Saga.pdf ) ร่วมกับ Event-sourcing (แนวคิด DDD) : http://en.wikipedia.org/wiki/Domain-driven_design ) โพสต์ที่ดีที่รวมเข้าด้วยกัน: https://blog.jonathanoliver.com/cqrs-sagas-with-event-sourcing-part-ii-of-ii/ ฉันได้รับคำถามในหนึ่งนาที แต่ฉันคิดว่าฉันต้องพยายามสรุปสิ่งที่ฉันเข้าใจก่อน (ซึ่งอาจผิดพลาดได้โปรดแก้ไขให้ถูกต้องหากเป็นกรณีนี้) เนื่องจากสิ่งนี้อาจส่งผลกระทบต่อสาเหตุที่ฉัน ถามคำถามเพื่อเริ่มต้นด้วย: รูปแบบ Saga คือนายหน้าประเภทหนึ่งที่ให้การกระทำ (ผู้ใช้ปลายทางอัตโนมัติ ฯลฯ โดยพื้นฐานแล้วอะไรก็ตามที่กำลังจะเปลี่ยนข้อมูล) จะแบ่งการกระทำนั้นในกิจกรรมทางธุรกิจและส่งกิจกรรมเหล่านี้เป็นข้อความไปยัง Message Bus ซึ่ง ในทางกลับกันส่งไปยังรากรวมที่เกี่ยวข้องที่จะได้รับการดูแล รากรวมเหล่านี้สามารถทำงานได้อย่างสมบูรณ์แบบอัตโนมัติ (แยกความกังวล, ปรับขยายได้ดี ฯลฯ ) Saga-instance นั้นไม่มีตรรกะทางธุรกิจใด ๆ ที่มีอยู่ในรากรวมที่มันส่งกิจกรรมไปให้ 'ตรรกะ' เพียงอย่างเดียวที่มีอยู่ใน Saga คือ 'กระบวนการ' - ตรรกะ (มักใช้เป็น Statemachine) …

15 domain-driven-design  cqrs  event-sourcing 

ฉันกำลังทำงานกับแอปพลิเคชันตัวอย่างขนาดเล็กเพื่อเรียนรู้แนวคิดของ CQRS และการจัดหากิจกรรม ฉันมีการBasketรวมและการProductรวมซึ่งควรทำงานอย่างอิสระ นี่คือโค้ดหลอกบางอย่างที่จะแสดงการใช้งาน Basket { BasketId; OrderLines; Address; } // basket events BasketCreated { BasketId; } ItemAdded { BasketId; ProductId; Quantity } AddItemSucceeded { BasketId; ProductId; Quantity } AddItemRevoked { BasketId; ProductId; Quantity } ItemRemoved { BasketId; ProductId; Quantity } CheckedOut { BasketId; Address } Product { ProductId; …

14 domain-driven-design  cqrs  event-sourcing 

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

14 cqrs  event-sourcing  eventual-consistency  read-model 

สมมติว่าเราต้องการใช้ระบบย่อยความปลอดภัยขนาดเล็กสำหรับแอปพลิเคชันทางการเงินที่เตือนผู้ใช้ทางอีเมลหากตรวจพบรูปแบบแปลก ๆ สำหรับตัวอย่างนี้รูปแบบจะประกอบด้วยสามธุรกรรมตามที่อธิบายไว้ ระบบย่อยความปลอดภัยสามารถอ่านเหตุการณ์จากระบบหลักจากคิว สิ่งที่ฉันต้องการได้รับคือการแจ้งเตือนที่เป็นผลโดยตรงจากเหตุการณ์ที่เกิดขึ้นในระบบโดยไม่มีการแสดงสื่อกลางที่เป็นแบบจำลองสถานะปัจจุบันของรูปแบบ เปิดใช้งานการตรวจสอบแล้ว ประมวลผลธุรกรรมแล้ว ประมวลผลธุรกรรมแล้ว ประมวลผลธุรกรรมแล้ว ทริกเกอร์แจ้งเตือน (id: 123) ส่งอีเมลเพื่อรับการแจ้งเตือน (สำหรับ id: 123) ประมวลผลธุรกรรมแล้ว เมื่อนึกถึงสิ่งนี้ฉันคิดว่าการจัดหากิจกรรมสามารถทำได้ที่นี่เป็นอย่างดีแม้ว่าฉันจะมีคำถามที่ไม่มีคำตอบที่ชัดเจน การแจ้งเตือนที่ทริกเกอร์ในตัวอย่างมีผลข้างเคียงที่ชัดเจนจำเป็นต้องส่งอีเมลสถานการณ์ที่ควรเกิดขึ้นเพียงครั้งเดียวเท่านั้น ดังนั้นจึงไม่ควรเกิดขึ้นเมื่อเล่นซ้ำเหตุการณ์ทั้งหมดของการรวมซ้ำ ในระดับหนึ่งฉันเห็นอีเมลที่ต้องส่งคล้ายกับการสร้างเนื้อหาที่สร้างขึ้นโดยฝ่ายแบบสอบถามที่ฉันเห็นมาหลายครั้งในวรรณกรรมการจัดหา CQRS / กิจกรรมด้วยความแตกต่างที่ไม่ลึกซึ้งนัก ในวรรณคดีนี้ด้านแบบสอบถามถูกสร้างขึ้นจากตัวจัดการเหตุการณ์ที่สามารถสร้างเป็นตัวเป็นตนของรัฐที่จุดที่กำหนดให้อ่านเหตุการณ์ทั้งหมดอีกครั้ง ในกรณีนี้แม้ว่าจะไม่สามารถบรรลุได้อย่างสมบูรณ์เช่นนั้นด้วยเหตุผลที่อธิบายไว้ก่อนหน้านี้ ความคิดที่ว่าทุกรัฐเป็นชั่วคราวใช้ไม่ได้เป็นอย่างดีที่นี่ เราต้องบันทึกความจริงที่ว่าการแจ้งเตือนถูกส่งไปที่ไหนสักแห่ง ทางออกที่ง่ายสำหรับฉันคือการมีตารางหรือโครงสร้างที่แตกต่างกันซึ่งคุณเก็บบันทึกการแจ้งเตือนที่ถูกเรียกใช้ก่อนหน้านี้ เนื่องจากเรามี ID เราจะสามารถตรวจสอบว่ามีการออกการแจ้งเตือนด้วย ID เดียวกันก่อนหน้านี้หรือไม่ การมีข้อมูลนี้จะทำให้ SendAlertCommand idempotent สามารถออกคำสั่งได้หลายคำสั่ง แต่ผลข้างเคียงจะเกิดขึ้นเพียงครั้งเดียว แม้จะมีวิธีแก้ปัญหานั้นในใจฉันก็ไม่รู้ว่านี่เป็นคำใบ้ว่ามีบางอย่างผิดปกติกับสถาปัตยกรรมนี้สำหรับปัญหานี้หรือไม่ วิธีการของฉันถูกต้องหรือไม่ มีสถานที่ใดบ้างที่ฉันสามารถค้นหาข้อมูลเพิ่มเติมเกี่ยวกับเรื่องนี้? มันแปลกที่ฉันไม่สามารถหาข้อมูลเพิ่มเติมเกี่ยวกับเรื่องนี้ได้ บางทีฉันอาจใช้ข้อความที่ไม่ถูกต้อง ขอบคุณมาก!

14 event-programming  cqrs  event-sourcing 

เรามีสถานการณ์ที่ฉันต้องรับมือกับเหตุการณ์ที่ไหลเข้ามาในเซิร์ฟเวอร์ของเราโดยเฉลี่ยประมาณ 1,000 เหตุการณ์ต่อวินาทีโดยเฉลี่ย ปัญหา ระบบของเราโฮสต์บนHerokuและใช้Heroku Postgres DBที่ค่อนข้างแพงซึ่งอนุญาตการเชื่อมต่อ DB ได้สูงสุด 500 เราใช้การเชื่อมต่อร่วมกันเพื่อเชื่อมต่อจากเซิร์ฟเวอร์ไปยังฐานข้อมูล เหตุการณ์เข้ามาเร็วกว่าการเชื่อมต่อฐานข้อมูลที่สามารถจัดการได้ ปัญหาที่เรามีคือเหตุการณ์เกิดขึ้นเร็วกว่าพูลการเชื่อมต่อที่สามารถจัดการได้ เมื่อถึงเวลาที่การเชื่อมต่อหนึ่งเสร็จสิ้นการส่งสัญญาณเครือข่ายจากเซิร์ฟเวอร์ไปยังฐานข้อมูลดังนั้นจึงสามารถปล่อยกลับไปที่กลุ่มได้มากกว่าnมีเหตุการณ์เพิ่มเติมเข้ามา ในที่สุดเหตุการณ์ต่างๆก็หมดลงรอรับการบันทึกและเนื่องจากไม่มีการเชื่อมต่อที่พร้อมใช้งานในกลุ่มจึงหมดเวลาและระบบทั้งหมดไม่สามารถใช้งานได้ เราได้แก้ไขเหตุฉุกเฉินด้วยการปล่อยเหตุการณ์ความถี่สูงที่ก้าวร้าวช้าลงจากลูกค้า แต่เรายังต้องการทราบวิธีจัดการสถานการณ์นี้ในเหตุการณ์ที่เราต้องจัดการกับเหตุการณ์ความถี่สูงนั้น ข้อ จำกัด ลูกค้ารายอื่นอาจต้องการอ่านเหตุการณ์พร้อมกัน ไคลเอนต์อื่น ๆ ร้องขออย่างต่อเนื่องเพื่ออ่านเหตุการณ์ทั้งหมดที่มีคีย์เฉพาะแม้ว่าพวกเขาจะยังไม่ได้บันทึกในฐานข้อมูล ไคลเอนต์สามารถสอบถามGET api/v1/events?clientId=1และรับเหตุการณ์ทั้งหมดที่ส่งโดยไคลเอนต์ 1 แม้ว่าเหตุการณ์เหล่านั้นจะยังไม่ได้ทำการบันทึกในฐานข้อมูล มีตัวอย่าง "ห้องเรียน" เกี่ยวกับวิธีจัดการกับเรื่องนี้หรือไม่? การแก้ปัญหาที่เป็นไปได้ จัดคิวเหตุการณ์บนเซิร์ฟเวอร์ของเรา เราสามารถจัดคิวเหตุการณ์บนเซิร์ฟเวอร์ (ด้วยคิวที่มีการเกิดพร้อมกันสูงสุด 400 เพื่อให้กลุ่มการเชื่อมต่อไม่หมด) นี่เป็นความคิดที่ไม่ดีเพราะ: มันจะกินหน่วยความจำเซิร์ฟเวอร์ที่มีอยู่ เหตุการณ์ที่จัดคิวเข้าด้วยกันจะใช้ RAM จำนวนมาก เซิร์ฟเวอร์ของเราเริ่มต้นใหม่ครั้งเดียวทุก 24 ชั่วโมง นี่เป็นข้อ จำกัด อย่างหนักจาก Heroku เซิร์ฟเวอร์สามารถรีสตาร์ทในขณะที่เหตุการณ์ถูกจัดคิวทำให้เราสูญเสียเหตุการณ์ที่จัดคิว มันแนะนำสถานะบนเซิร์ฟเวอร์จึงทำร้ายความยืดหยุ่น …

13 architecture  performance  scalability  event-sourcing 

ฉันได้อ่านเกี่ยวกับการออกแบบการขับเคลื่อนด้วยโดเมนเป็นเวลาเกือบสองปีและได้รับการแนะนำแนวคิดบางอย่างเกี่ยวกับการทำงานประจำวันของฉันอย่างน้อยหรือวางแผนอย่างน้อยสำหรับสิ่งที่ฉันทำเป็นประจำในการออกแบบโดเมนที่ขับเคลื่อนได้ ข้อสรุปหนึ่งที่ฉันได้เริ่มมาโดยเฉพาะอย่างยิ่งในการตอบสนองต่อการอ่านเพิ่มเติมเกี่ยวกับการจัดหากิจกรรมและการแยกความรับผิดชอบคำสั่งแบบสอบถาม (CQRS) ที่บางทีวัตถุโดเมนมีวัตถุประสงค์ที่จะใช้สำหรับการเขียนเท่านั้น เพื่อให้ชัดเจนยิ่งขึ้นดูเหมือนว่าสิ่งที่ผู้คนแนะนำอย่างละเอียดในเอกสารส่วนใหญ่ที่ฉันได้อ่านว่าวัตถุโดเมนมีหน้าที่ในการดำเนินการ / การคำนวณโดเมนเป็นศูนย์กลางการตรวจสอบความถูกต้องและจากนั้นส่วนใหญ่จะเป็นถนน โครงสร้างพื้นฐานที่มีให้ภายในการใช้พื้นที่เก็บข้อมูล แม้ว่าฉันจะชอบความจริงที่ว่าสิ่งนี้อาจลดความซับซ้อนของโมเดลโดเมนลงอย่างมากเนื่องจากช่วยลดความรับผิดชอบในการเปิดเผยสถานะ ถ้ามันถูกต้องจริง ๆ แล้วว่าวัตถุโดเมนส่วนใหญ่จะใช้เป็นวัตถุแบบเขียนอย่างเดียวแล้วนั่นทำให้เกิดคำถามสำหรับฉันที่ฉันหวังว่าใครบางคนสามารถตอบ วิธีการหนึ่งทำการทดสอบหน่วยบนวัตถุที่มี setters หรือวิธีการที่ปรับเปลี่ยนสถานะของวัตถุ แต่ที่ให้ไม่มีส่วนต่อประสานภายนอกสาธารณะเพื่ออ่านสถานะจากเช่น getters คุณสมบัติใน C #? มันโอเคที่จะเปิดเผยสถานะเพียงเพื่อจุดประสงค์ในการทำให้วัตถุนั้นทดสอบได้หรือไม่? ผู้ใช้จะแสดงผลลัพธ์ของการคำนวณหรือการดำเนินการในโดเมนโดยไม่ต้องยืนยันพวกเขาได้อย่างไรแล้วดึงผลลัพธ์จากการเก็บข้อมูลไว้ภายนอกบริบทของโดเมน การเปิดเผยสถานะเพียงเพื่อจุดประสงค์ในการแสดงผลลัพธ์เท่านั้นหรือไม่ เป็นกฎของหัวแม่มือที่ควรได้รับทรัพย์สินเท่านั้น (รับ accessors) เป็นคนที่สามารถเขียนได้ในโดเมน? หรือกล่าวว่าคุณสมบัติที่แตกต่างกันอย่างอ่านง่ายควรเป็นสิ่งเดียวที่ควรหลีกเลี่ยงเนื่องจากมีไว้เพื่อการอ่านเท่านั้นและไม่ได้มีบทบาทที่จำเป็นในแบบจำลองโดเมนจริงหรือ วัสดุที่เกี่ยวข้อง: TDD, DDD และ Encapsulation

13 domain-driven-design  domain-model  cqrs  event-sourcing 

ฉันกำลังศึกษาการออกแบบโดยใช้โดเมน (DDD) และพบเจอกัน: Event Driven และ Event sourcing ฉันรู้ว่ามันเกี่ยวกับการเผยแพร่กิจกรรมจากผู้ผลิตสู่ผู้บริโภคและจัดเก็บบันทึกดังนั้นคำถามของฉันคือ: การขับเคลื่อนกิจกรรมและการจัดหากิจกรรมแตกต่างกันอย่างไร

13 event-sourcing 

ฉันได้อ่านเกี่ยวกับการจัดหากิจกรรมเมื่อเร็ว ๆ นี้และชอบความคิดที่อยู่เบื้องหลัง แต่ติดอยู่กับปัญหาต่อไปนี้ สมมติว่าคุณมีกระบวนการที่เกิดขึ้นพร้อมกัน N กระบวนการซึ่งรับคำสั่ง (เช่นเว็บเซิร์ฟเวอร์) สร้างเหตุการณ์เป็นผลลัพธ์และเก็บไว้ในที่จัดเก็บส่วนกลาง สมมติว่าสถานะแอพพลิเคชั่นชั่วคราวทั้งหมดนั้นถูกเก็บรักษาไว้ในหน่วยความจำของแต่ละกระบวนการโดยการใช้เหตุการณ์ตามลำดับจากที่จัดเก็บ ตอนนี้สมมติว่าเรามีกฎเกณฑ์ทางธุรกิจดังต่อไปนี้ผู้ใช้แต่ละคนต้องมีชื่อผู้ใช้ที่ไม่ซ้ำกัน หากทั้งสองกระบวนการได้รับคำสั่งการลงทะเบียนผู้ใช้สำหรับชื่อผู้ใช้ X เดียวกันพวกเขาทั้งคู่ตรวจสอบว่า X ไม่ได้อยู่ในรายการชื่อผู้ใช้กฎจะตรวจสอบความถูกต้องของกระบวนการทั้งสองและพวกเขาทั้งสองเก็บเหตุการณ์ "ผู้ใช้ใหม่ . ขณะนี้เราได้ป้อนสถานะโกลบอลที่ไม่สอดคล้องกันเนื่องจากละเมิดกฎธุรกิจ (มีผู้ใช้สองรายที่แตกต่างกันด้วยชื่อผู้ใช้เดียวกัน) ในเซิร์ฟเวอร์ N แบบดั้งเดิม <-> 1 ระบบสไตล์ RDBMS ฐานข้อมูลจะใช้เป็นจุดศูนย์กลางของการซิงโครไนซ์ซึ่งช่วยป้องกันความไม่สอดคล้องดังกล่าว คำถามของฉันคือโดยทั่วไปแล้วเหตุการณ์ที่มาจากระบบจะแก้ไขปัญหานี้ได้อย่างไร พวกเขาเพียงแค่ประมวลผลทุกคำสั่งตามลำดับ (เช่น จำกัด จำนวนของกระบวนการที่สามารถเขียนไปยังร้านค้าถึง 1)?

12 distributed-computing  event-sourcing  eventual-consistency 

โดยทั่วไปฉันพยายามจะคลุมหัวแนวคิดของCQRSและแนวคิดที่เกี่ยวข้อง แม้ว่า CQRS ไม่จำเป็นต้องรวมการส่งข้อความและการจัดหากิจกรรม แต่ดูเหมือนว่าจะเป็นการผสมผสานที่ดี ได้รับกรณีการใช้งานสำหรับการเปลี่ยนแปลงสถานะสำหรับบางสิ่ง (พูดเพื่ออัปเดตคำถามเกี่ยวกับ SO) คุณจะพิจารณาว่าโฟลว์ต่อไปนี้ถูกต้องหรือไม่ ระบบออกรวม UpdateQuestionCommand ซึ่งอาจแยกออกเป็นสองคำสั่งเล็ก: UpdateQuestion ซึ่งมีการกำหนดเป้าหมายที่ Root Aggregate คำถามและ UpdateUserAction (เพื่อนับคะแนน ฯลฯ ) กำหนดเป้าหมายที่ User Aggregate Root สิ่งเหล่านี้ส่งแบบอะซิงโครนัสโดยใช้การส่งข้อความแบบจุดต่อจุด รากรวมทำสิ่งของพวกเขาและถ้าทุกอย่างดำเนินไปได้ดีกับเหตุการณ์ QuestionUpdated และ UserActionUpdated ตามลำดับซึ่งมีสถานะที่ถูกเอาต์ซอร์ซไปยัง Event Store .. เพื่อที่จะยืนยัน yadayada ให้เสร็จสมบูรณ์ไม่ใช่จุดที่นี่จริงๆ เหตุการณ์เหล่านี้จะถูกวางในคิว pub / sub เพื่อออกอากาศ ผู้สมัครสมาชิกใด ๆ (ซึ่งมีแนวโน้มว่าจะมีหนึ่งหรือหลายโปรเจ็คเตอร์ที่สร้างมุมมองอ่าน) มีอิสระที่จะสมัครสมาชิกกับเหตุการณ์เหล่านี้ คำถามทั่วไป: เป็นวิธีปฏิบัติที่ดีที่สุดจริง ๆ หรือไม่ที่คำสั่งนั้นสื่อสารแบบจุดต่อจุด …

12 domain-driven-design  cqrs  event-sourcing 

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

12 event-sourcing 

ฉันต้องการใช้แอปพลิเคชันแรกของฉันโดยใช้รูปแบบ CQRS พร้อมกับการจัดหากิจกรรม ฉันสงสัยว่าการสร้างรากรวมควรได้รับการจัดการอย่างเหมาะสมอย่างไร สมมติว่ามีคนส่งคำสั่ง CreateItem ควรจัดการอย่างไร? รายการเหตุการณ์ที่สร้างขึ้นควรเก็บไว้ที่ไหน เป็นกิจกรรมแรกของรายการใหม่หรือไม่ หรือฉันควรจะมีรายการ ItemList บางอย่างที่รวมรายการทั้งหมดและรายการเหตุการณ์ประกอบด้วยรายการของ ItemCreated เท่านั้น Udi Dahan ไม่แนะนำให้สร้างรากรวมและมักจะใช้วิธีดึงข้อมูลบางอย่างแทน แต่วิธีที่ฉันสามารถดึงข้อมูลบางอย่างที่ใหม่และแน่นอนไม่มี ID ใด ๆ ที่ได้รับมอบหมาย ฉันเข้าใจความคิดที่อยู่เบื้องหลังและมันค่อนข้างสมเหตุสมผลที่จะคิดว่าวัตถุใหม่เป็นวัตถุที่มีสถานะเป็นศูนย์ซึ่งประกอบด้วยเหตุการณ์ที่ตอบกลับเป็นศูนย์ แต่ฉันจะใช้มันได้อย่างไร ฉันควรจะมีวิธีการที่แตกต่างกันในพื้นที่เก็บข้อมูลของฉันเช่นgetNewItem()หรือทำให้get(id)วิธีการของฉันยอมรับOptional<ItemId>แทน? แก้ไข: หลังจากการขุดสักพักฉันพบว่าการใช้รูปแบบดังกล่าวน่าสนใจจริง ๆโดยใช้นักแสดง ผู้เขียนแทนที่จะสร้างผลรวมดึงข้อมูลจากที่เก็บบางประเภทด้วย UUID ที่สร้างขึ้นใหม่ ข้อเสียเปรียบของวิธีนี้คือเขาอนุญาตให้มีสถานะที่ไม่สอดคล้องกันชั่วคราว ฉันยังสงสัยว่าฉันสามารถใช้deleteวิธีการด้วยวิธีดังกล่าวได้อย่างไร เพียงเพิ่มเหตุการณ์ที่ถูกลบไปยังรายการกิจกรรมของการรวมหรือไม่

11 domain-driven-design  repository  cqrs  event-sourcing