我目前正在開發一個多租戶系統，我已經實作了混合流，允許每個客戶使用單個資料庫和基于請求的共享資料庫，
但是，某些客戶需要一些自定義，因為他們的流程略有不同，但我只有一個跨系統的用戶流。
如何在不影響系統上的其他客戶的情況下為客戶實施此自定義？
請查看我當前的架構
編輯：定制主要與用戶旅程相關，例如工資單系統，客戶 A 希望將工資單發送給 MD 進行審批，而客戶 B 希望會計師在 MD 之前批準。
uj5u.com熱心網友回復：
如果我們在談論資料庫。
我要做的是為他們的定制添加一個 json 型別的物件
就像添加一個 custom_fields 列
Customer Table
//your properties
custom_fields : nvarchar(max)
帶有樣本值
custom_fields
NULL //for customers without custom_fields
{"CustomFieldA" : "ValueForA", "CustomFieldB" : "ValueForB"} \\for customers with specific request
然后在 c# 端，在動態物件或確定的類上反序列化它。
//if not determined
var customField = JsonSerializer.Deserialize<ExpandoObject>(jsonString);
然后訪問該值
foreach (var key in customField.Select(x => x.Key))
{
//to get the custom property name
var propertyName = key.ToString();
//to get the value
var value = customField.First(x => x.Key == key).Value;
}
uj5u.com熱心網友回復：
從高層次的角度來看，在運行在同一架構上的多租戶解決方案中，我們可以通過對所有租戶嚴格應用所有架構更改來解決很多問題，而不僅僅是那些請求更改的租戶。
如果可以避免，甚至不要考慮動態模式，而是改進產品，以便所有租戶都能享受到好處，并拒絕那些太難或與您的核心產品不匹配的請求。
可以拒絕 （或要求淫穢費用以使其值得付出努力）
訣竅是以向后兼容的方式實作任何更改，如果類獲得新屬性但您不希望它們自動對所有租戶可用，則使用繼承來擴展類，如果您引入了新關系，請將它們設為可選。如果您已經將表示層與資料模型充分分離，那么保留不使用新屬性的先前視圖并有效地為需要新屬性的任何視圖設定外觀應該沒有任何問題。
如果您的域模型可以抽象為有效的檔案管理，則主要流程管理和配置方面將不需要了解特定的租戶業務模型，只需了解抽象，在這種情況下可以使用 JSON 或 XML 序列化技術，如描述在這個回應中。
一個很好的例子是3rd 方物流或經紀應用程式中的寄售、清單和采購訂單，域模型只能通過一組通用識別符號和一些常見的描述欄位松散地跟蹤寄售和行專案，但原始內容可以序列化并存盤到資料庫中的單個欄位中，因為大多數資料和處理操作不需要了解特定內容或其結構。
這在第三方物流頻繁出現如使用不同的資料平臺和軟體不同的載波與發送端和接收端兩個客戶端互動，多個物體可能之間TBUT這些物體沒有任何參與owernship資料或權利在本質上是飛行程序中對其進行修改。
資料的生命周期涉及攝取、多階段處理、通知和某種形式的輸出。在攝取時，我們應用特定的轉換來解釋標準模式需要從資料中了解什么，但對于其他所有內容，通常可以以原生形式查看序列化內容，這意味著對于每個自定義資料型別，都會有相應的轉換到標準模型和可以呈現本機形式的視圖。
如果唯一的變化是資料處理的編排，那么除了流程步驟的配置和一些狀態管理之外，實際上不需要太多模式更改來實作。
想到的可能的編排解決方案是 Azure Functions、Azure Durable Functions、邏輯應用程式或其他作業流引擎。即使您已經擁有可以執行各種任務和操作的核心 API 或代碼庫，您仍然可以使用作業流技術根據配置的觸發器執行這些端點。
您還可以研究用于處理資料、Web 鉤子或領域事件的更微服務風格的架構，從模式的角度來看可能會有所幫助，閱讀領域驅動設計中的領域事件與集成事件以及微服務架構
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/383686.html
上一篇：如果陣列元素發生變化，則可觀察