Cqrs Example Php,Broadway - 一个事件源和CQRS库

Broadway是一个为创建CQRS(命令查询责任分离)和事件源应用程序提供基础设施和测试帮助的项目。它包含多个松散耦合的组件,可以组合使用以提供完整的CQRS/ES体验。此项目已在生产环境中使用,适合有一定经验的开发者。项目还提供了Symfony和Laravel的集成方案,并鼓励其他项目的贡献。博客中包含了安装、示例、组件介绍和贡献者信息。
摘要由CSDN通过智能技术生成

Broadway

Broadway is a project providing infrastructure and testing helpers for creating CQRS and event sourced applications. Broadway tries hard to not get in your way. The project contains several loosely coupled components that can be used together to provide a full CQRS\ES experience.

Note: while broadway is currently used in production, you should probably know what you're doing. ;)

68747470733a2f2f7472617669732d63692e6f72672f71616e6469646174652d6c6162732f62726f61647761792e7376673f6272616e63683d6d6173746572

Feel free to join #qandidate on freenode with questions and remarks!

About

Read the blog post about this repository at:

Installation

$ composer require broadway/broadway

Examples

Examples can be found in the examples/ directory. Most of the examples focus on showing how one of the components works. There is also a more deliberate example using several components and showing how you can test your event sourced model.

Components

Broadway consists of several components. Check out the README's of each component for more information.

Integrations

The broadway project ships with a bundle to use with a Symfony application.

A Laravel package is also available to allow the use of Broadway inside a Laravel application.

Contributions for integrations with other projects are appreciated!

Acknowledgements

The broadway project is heavily inspired by other open source project such as AggregateSource, Axon Framework and Ncqrs.

We also like to thank Benjamin, Marijn and Mathias for the conversations we had along the way that helped us shape the broadway project. In particular Marijn for giving us access to his in-house developed CQRS framework.

License

MIT, see LICENSE.

目錄 第1章 我們的領域: 會議管理系統1 1.1 Contoso公司簡介1 1.2 誰與我們同行2 1.3 Contoso會議管理系統3 1.3.1 系統概覽3 1.3.2 非功能性需求4 1.4 開始我們的旅程5 1.5 更多信息5 第2章 領域分解——站點規劃6 2.1 本章術語定義6 2.2 會議管理系統裡面的有界上下文7 2.2.1 訂單和註冊有界上下文7 2.2.2 會議管理有界上下文7 2.2.3 支付有界上下文8 2.2.4 不包括在內的有界上下文8 2.2.5 Contoso會議管理系統的上下文路線圖9 2.3 為什麼選擇這些有界上下文10 2.4 更多信息11 第3章 訂單和註冊有界上下文12 3.1 訂單和註冊有界上下文簡介12 3.2 本章術語定義13 3.3 領域定義(普適語言)14 3.4 訂單創建的需求分析16 3.5 系統架構17探索CQRS事件目錄3.6模式和概念17 3.6.1 系統驗證21 3.6.2 交易邊界22 3.6.3 併發處理22 3.6.4 Aggregates和Aggregate Roots22 3.7 實現細節23 3.7.1 高層架構23 3.7.2 寫者模型28 3.7.3 使用Windows Azure服務匯流排37 3.8 對測試的影響44 3.9 本章小結47 3.10 更多信息47 第4章 擴展和改進訂單和註冊有界上下文48 4.1 修改有界上下文48 4.1.1 本章術語定義49 4.1.2 用戶需求49 4.1.3 系統架構49 4.2 模式和概念51 4.2.1 記錄定位器51 4.2.2 讀者端查詢51 4.2.3 向讀者端提供部分履行的訂單信息54 4.2.4 CQRS命令驗證55 4.2.5 倒計時定時器和讀者模型56 4.3 實現細節56 4.3.1 訂單訪問碼(記錄定位器)57 4.3.2 倒計時定時器58 4.3.3 使用ASP.NET MVC驗證60 4.3.4 將改動推送到讀者端62 4.3.5 重構SeatsAvailability aggregate66 4.4 對測試的影響68 4.4.1 接受測試和領域專家68 4.4.2 使用SpecFlow功能來定義接受測試68 4.4.3 通過測試來幫助開發人員理解消息流75 4.5 代碼理解的旅程: 痛苦、釋放和學習的故事77 4.5.1 測試很重要77 4.5.2 領域測試78 4.5.3 硬幣的另外一面80 4.6 本章小結83 4.7 更多信息84 第5章 準備V1發布85 5.1 Contoso會議管理系統的V1發布版85 5.1.1 本章術語定義85 5.1.2 用戶需求86 5.1.3 系統架構87 5.2 模式和概念91 5.2.1 事件91 5.2.2 基於任務的用戶界面92 5.2.3 有界上下文之間的集成95 5.2.4 分散式交易和事件98 5.2.5 自治與集權99 5.2.6 讀者端的實現方法100 5.2.7 最終一致性100 5.3 實現細節101 5.3.1 會議管理有界上下文101 5.3.2 支付有界上下文102 5.3.3 事件105 5.3.4 基於Windows Azure表格的事件庫111 5.3.5 訂單總價計算114 5.4 對測試的影響114 5.4.1 時序問題114 5.4.2 引入領域專家115 5.5 本章小結115 5.6 更多信息115 第6章 系統版本控制116 6.1 本章術語定義116 6.1.1 用戶需求116 6.1.2 系統架構117 6.2 模式和概念118 6.2.1 修改事件定義118 6.2.2 確保消息的自洽性119 6.2.3 集成事件的保存121 6.2.4 消息排序122 6.3 實現細節123 6.3.1 對零成本訂單的支持123 6.3.2 顯示剩餘座位數127 6.3.3 刪除重複命令130 6.3.4 確保消息排序131 6.3.5 保存會議管理有界上下文的事件135 6.3.6 從V1版本遷移到V2版本139 6.4 對測試的影響140 6.4.1 重訪SpecFlow140 6.4.2 在遷移過程中發現錯誤143 6.5 本章小結143 6.6 更多信息144 第7章 加入彈性和優化性能145 7.1 本章術語定義145 7.2 系統架構145 7.3 加入彈性147 7.3.1 增加事件重複處理時的彈性148 7.3.2 確保命令的發送148 7.4 優化性能148 7.4.1 優化前的用戶界面流程149 7.4.2 用戶界面優化150 7.4.3 基礎設施優化151 7.5 無停機遷移158 7.6 實現細節159 7.6.1 改進RegistrationProcessManager類160 7.6.2 用戶界面流程優化165 7.6.3 消息的非同步接收、處理和發送170 7.6.4 在流程內部對命令進行同步處理171 7.6.5 使用備忘錄模式來實現快照173 7.6.6 對事件進行並行發布175 7.6.7 在訂購服務裡面對消息進行過濾176 7.6.8 為SeatsAvailability aggregate創建專門的SessionSubscriptionReceiver實例177 7.6.9 緩存讀者模型數據179 7.6.10 使用多個議題來劃分服務匯流排180 7.6.11 其他的優化和強化措施181 7.7 對測試的影響184 7.7.1 集成測試185 7.7.2 用戶界面測試185 7.8 本章小結185 7.9 更多信息185 第8章 尾聲: 經驗教訓186 8.1 我們學到了什麼186 8.1.1 性能很重要186 8.1.2 實現消息驅動並不簡單187 8.1.3 雲平台的挑戰187 8.1.4 不同的CQRS188 8.1.5 事件和交易日誌記錄190 8.1.6 引入領域專家190 8.1.7 什麼時候該使用CQRS190 8.2 如果重新來過,我們會做的有什麼不同191 8.2.1 以牢靠的消息和保存基礎設施為起點191 8.2.2 更好地利用基礎設施的能力191 8.2.3 採納更加系統化的方法來實現流程管理器192 8.2.4 對應用程序實施不同的劃分192 8.2.5 以不同方式組織項目團隊192 8.2.6 對領域和有界上下文的CQRS適用性進行評估192 8.2.7 為性能進行規劃192 8.2.8 重新考慮用戶界面193 8.2.9 探索事件的其他用處193 8.2.10 探索有界上下文的集成問題193 8.3 更多信息194
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值