JHipster微服務實體

Question

我讀了BFF pattern，我有一個疑問，如果一個微服務僅適用於iOS，而其他微服務僅適用於Android，那麼如果兩個服務使用相同的數據庫和相同的表，那麼必須如何創建實體？

我試圖使用JDL-Studio和進口與進口IDL命令的模型，但我不知道是否該命令必須在每個微服務的工作空間

編輯運行：

對於更多的情況下，我想建立一個可以有很多併發的從網頁，iOS和Android應用程序與REST調用的全棧的應用程序，我不知道是否正確的重複實體在每一個微服務（已分離API for each plataform）或者只添加一個微服務作爲數據庫層。

編輯2： 我發現這個blog談論創建微服務jhipster應用和這傢伙表演如何網關都自己擁有實體和微服務有他們自己太..

現在，我有更多的清除微服務體系結構的真正基礎，但是如果我想要一個帶有所有實體的微服務和只有UI實體的網關呢？博客的節目怎麼可能是這樣，但只有一個實體，我有一個完整的model.jhl與所有實體

Answer 1

我不會從原來的主後端API應用程序中使用進口IDL任何人分開。您不需要爲每個BFF提供完整的後端堆棧，否則您將不得不維護多個應用程序，而這些應用程序要做的是相同的事情，而且還需要將這些數據源之間的數據同步到某種「主」。如果您將所有內容重新命名爲單個數據庫並共享BFF組件之間的所有實體，則它不適合微服務模型。

的BFF圖案被認爲是在一個現有的服務API，其過濾的前一薄門面和或許調用多個服務API必要時骨料的東西，以適應每個客戶端類型。當您無法控制現有的API或增量服務分解中的（臨時）步驟時，我發現這種模式更像是一種方便的創可貼。理想情況下，微服務不應該具有這種同步依賴關係，而且我也不是橫向分解的狂熱粉絲。

在我看來還有，如果從頭開始，而不復雜的架構和添加的附加延遲又間接的另一層制定實施「BFF」功能的更好的方法。微服務體系結構通常與UNIX命令進行比較。相同的UNIX命令能夠在需要時提供更詳細的信息以適應不同的需求。例如，比較ls與ls -l的輸出。這種策略也可以應用於單個微服務端點。