在開發系統時，如果測試情境的輸出會有許多資料類別並且要驗證很多欄位時，會利用 object graph 比對整個結果是否和預期一致。
現在我的專案裡有個 CustomerRootData 類別，裡頭屬性為十幾個不同型別的子集合，每個類別都有 UpdateTime、UpdateUser 這兩個欄位，但這兩個欄位是在程式執行當下才寫進去的，不屬於測試驗證的重點，在寫測試的時候常常陷入重複設定的地獄。
於是在 AwesomeAssertions / AwesomeAssertions Object Graphs 的架構下，想辦法在做比對時去做到比較方便省事的設定方法，讓我輕鬆地去排除指定的欄位。
在找尋資料、解決方法的同時，也讓我得知不一樣的處理方式，將這些處理方式用文章記錄下來，也提供給大家做個參考。
其實這也不是新聞了，早在今年 1/15 時大家就已經知道並且被商業授權的費用給嚇了一大跳（每個人 $129.95 USD）。
現在特地寫一篇是因為上週因為 AutoMapper 將要變成商業化授權而寫了兩篇文章介紹替代套件，就想到好像並沒有對於 Fluent Assertions 轉變為商業授權去寫一篇文章與替代方案，於是就以 Fluent Assertions 從 v8.0.0 起轉為商業授權，簡單寫了這篇去說明授權限制、專案應對策略，以及替代的 Assertion Library，提供給大家做個參考。
Mapperly 在以前找尋替代 AutoMapper 的時候就有看過，但當時著重在與 AutoMapper 設定與操作習慣相近的替代套件，所以對於 Mapperly 就沒有太多的關注。
直到寫了「替換映射工具 - 使用 Mapster」這篇文章後才稍微去看看 Mapperly，發現到它和 AutoMapper, Mapster 雖然都是屬於 Mapping 工具，都是做物件對映轉換的處理，但設定與使用上就有蠻大的差別，所以寫篇文章做個簡單的紀錄。
其實四年前就已經將手邊專案由原本所使用的 AutoMapper 以 Mapster 取代了。
起初的原因是效能考量，因為 AutoMapper 的效能一直被人詬病，但也因為 AutoMapper 的優點在於功能豐富、配置設定靈活，能夠處理複雜的 Mapping 需求，以致於我在帶新人的時候還是以 AutoMapper 為主，但是前些日子得知 AutoMapper 在之後也將走上商業化（跟 Fluent Assertions 一樣），所以就藉此來寫篇文章簡單介紹 Mapster。
過去工作專案大多使用 RabbitMQ 來處理訊息佇列，RabbitMQ 的幾種模式（Direct, Topic, Fanout）都有使用，因為都可以解決大多數的應用情境，所以就沒有想要去使用 Kafak，畢竟多建立一套服務就需要再多花時間去維護。
一直以來也想要找個時間來玩玩 Kafka，於是就利用週末時間學習怎麼使用 Docker 架設服務，程式開發練習怎麼使用 Confluent.Kafka，這是一篇學習筆記。
前一篇「使用 Wolverine 實作生產者-消費者模式（Producer-Consumer Pattern）」介紹了將原本使用 Channels + BackgroundService 的生產者-消費者模式改用 Wolverine 來實作。
就以現實的問題來看，如果服務是相當頻繁地被使用時，如果 MessageCreatedEventHandler 消費者的處理速度有所延遲，那麼 Channels 裡就會堆積大量的 MessageCreatedEvent 事件，一旦服務出現問題而重新啟動或是有版本更新而需要重新部署，那麼佇列在 Channels 裡的事件就會消失不見了，這可是不得了的事情。所以這篇就來用 WolverineFx.RabbitMQ，生產者將事件發送到 RabbitMQ 裡，然後消費者再去接收存放在 RabbitMQ 裡的訊息，如此的改變就是為了避免因為服務重新啟動而讓佇列在 Channels 裡的事件消失不見。
從 .NET Framework 開發 WebApi 服務時就開始使用 Swagger UI，直到現在都已經是直接在預設的 ASP.NET Core WebApi 專案範本裡就包含在內。
但是… 我一直都覺得 Swagger UI 做為 API 文件工具並不是很好閱讀，要查看輸入參數或輸出資料格式內容都不是那麼方便，我想大家或多或少應該都有這樣的感覺，所以我都還會在專案裡安裝 ReDoc 套件，ReDoc 做為 API 文件工具來檢視 API 的輸出入各種資訊都相當直觀且清楚，比 Swagger UI 更好閱讀，但是 ReDoc 只是個單純的 API 文件檢視工具，無法在 ReDoc 裡測試執行 API。
所以之前看到 Scalar 這個新的 API 文件檢視工具時就讓我眼睛一亮，有著如同 ReDoc 一般的 UI 外觀，可以方便且直覺地查看 API Endpoints 的資訊，而且還可以直接在上面測試執行 API，所以就趕緊來試試看。
過去的工作專案為了要加快 Request 的回應速度，所以就想方設法地去做了很多的調整…
例如一個訊息建立後要做很多的事情，像是要許多相關資料 Table 的資料異動、透過 RabbitMQ 去發送 message 通知其他 Client、快取資料的更新等等等
這麼多的處理如果都是在一個 Request 裡全部處理完成後才回傳 Response 結果，因為每個處理都會花費一些時間，全部累積起來就相當可觀，於是就會想到是不是要往平行處理或多執行緒的方式來解決，但是在繁忙的網站服務去使用這些解決方案又有很多風險，程式沒有寫好的話就會出現嚴重錯誤。
所以就想到用發送事件的方式，當訊息建立完成後，就發送一個事件到一個佇列裡，然後有一個 BackgroundService 去專門接收訊息建立完成事件，當收到事件後就開始一連串的處理，這麼一來 Action 方法的回應時間就能夠加快一些。
上一篇「背景常駐執行計時工作 - 使用 BackgroundService 與 PeriodicTimer」介紹了使用 BackgroundService 與 PeriodicTimer 實作計時的工作處理。
但如果有時候一些工作處理並不是每幾秒鐘或每幾分鐘、每幾個小時這樣的週期行為時，使用 PeriodicTimer 就無法滿足這樣的需求，而在使用 Hangfire 建立 Recurring Job 時都會使用到 Cron Expression 去定義工作的執行週期，而就有看到這麼一個 NuGet 套件就有提供這樣的功能，所以就拿來試試看。
背景常駐執行計時工作的實作方式有很多種，而我習慣在 ASP.NET Coe Web Application 使用 BackgroundService 然後搭配 Task.Delay 的方式來完成計時執行工作的處理，而在 .NET 6 提供了 PeriodicTimer 後就可以更方便的處理計時工作，這篇就來認識執行計時工作的幾種實作方式。
