SOA服務邊界和生產支持

Question

我們的開發團隊正在努力與服務目錄建立。

現在，我們有兩個組，一組到產品銷售，另一種以服務產品。 我們有一個特定的服務來計算產品的價格是否有利可圖。銷售發生時，銷售可以由經理覆蓋。此次銷售也必須在另一個系統中有所體現，以跟蹤各種銷售情況並且數字必須匹配。盈利能力的參數也是變化的，並且每個月都有所不同，但是銷售可以基於之前的一組參數。

眼下銷售利潤率服務只計算利潤，它也提供了一個RESTful URI。開發商

一組建議，盈利服務還支持這些「經理覆蓋」，並支持基於以前日期的日期參數來計算。當然，開發團隊的銷售人員不同意。如果服務不支持這一點，那麼服務開發人員將不得不在兩個系統之間爲每個產品執行ETL，而不僅僅是利潤服務。現在，由於我們沒有一套服務來處理這個問題，所以生產支持獲得了請求，然後必須更新與給定產品關聯的1+系統。

所以，如果一個服務適用於很小的一部分，但一個例外基於業務流程打破它，這是否意味着服務的邊界是不正確的，需要考慮業務流程的變化？

二，不添加日期參數延長了服務的邊界太多，或者是否應該例外，如果該服務已經擁有的參數，它也將有參數的歷史呢？目前，我們並沒有一項只存儲參數的服務，因爲沒有人需要它。

如果有需要可以給出答案之前，任何澄清，請讓我知道。

Answer 1

我認爲這裏的關鍵是：多少痛苦的人會通過，如果和ETL之間被引入到兩個兩隊將發生？

不是我認爲你過分分析了這一點，但如果可能的話，你可能會認爲在服務合約中添加日期參數是不好的，但也不喜歡ETL的想法。

好吧，拋開戰略，我覺得這幾天我的首要本能是不太注重技術來龍去脈，更對純粹的實用。

在這一天結束時，ETL是簡單的，可靠的，且相對無痛苦來實現，但是它帶有的副作用。主要的一點是，你會將變更與你的服務的數據庫模式結合到一個外部方，這將限制選項在將來發展你的服務。另一方面，允許消費者需求決定服務發展是容易的和低摩擦的，但也是一條崎嶇的道路，因爲您可能會犧牲其他消​​費者而屈服於該消費者。

另一種可能性是允許額外的服務參數通過message被交付給消費者，而不是在同樣的服務。這將允許您保持服務邊界的完整性，並讓消費者保持本地的必要參數。

道歉，如果這並不直接解決您的問題。