這裏藉由一個「放入購物車」的極小型功能案例，並利用 UML 各面向的設計圖，來表達微服務 (Microservices) 的架構規劃與設計的呈現樣貌。下列是幾個主要設計面向的設計圖 (並非是全部) 可以參考。
系統功能與實現程序
利用 UML 使用案例模型 (use case model) 與系統循序 (sequence) 圖表達「放入購物車」的系統功能與主要實現程序。
- 從需求模型可以看出共有兩個微服務：「Product Microservice」與「購物車 Microservice」。
- 每一個微服務均各有資料庫，圖中可看出共有兩個。資料庫是私有倉儲，不能跨微服務直接存取 (即使位於同一區域都不行)，只能透過 API 呼叫。
系統部署
利用 UML 系統部署 (Deployment) 圖表達了「Web Portal」、「API Gateway」、「Product & 購物車 Microservices」之間的系統連結。
- 系統之間的連結是透過 REST API，這是比較通用，但不是絕對只能採用該通訊協定。
- 「API Gateway」擔任類似 Router 的轉址，係屬於底層系統伺服器 (server)層級，一般並非是由 Application Developer 開發，而是可以採用商用/開源的產品。
微服務內部的分層結構
利用 UML 套件 (package) 圖規劃了每一個微服務內部的分層結構。網路上文章大都採以垂直 Layer 的方式來表達分層，個人仍是偏好採用老派 (old-school) 的水平 Tier 分層方式，來表達出「展示 (Presentation)層」、「應用邏輯 (Application Logic)層」、「資料存取 (Data Access) 層」與「資料來源 (Data Source)層」。
- Web API 係屬於展示層 (一般是透過 Controller 的實作)，負責接收 REST Client 的 Request，傳進的參數爲 JSON 資料結構。
- 微服務內部各層物件之間的連結，可以直接傳遞 JSON 當爲參數與回傳值，或者也可以在展示層就轉換 (transform)爲 資料傳遞物件 (DTO, Data Transfer Object)，兩者格式的互轉是很容易的，一般都有現成的工具物件可以直接使用。
- 資料存取層的存取物件在微服務的術語稱爲「Repository (儲庫)」，從名字就可以得知它是多個 Service 物件功用存取的。一般在大型 (Monolithic)系統的 DAO (Data Access Object) 物件最好不要設計爲共用，會非常的龐大擁腫；但由於微服務係由 Bounded Context 或功能模組界定了領域邊界 (domain boundary)，範圍已侷限，所以「Repository」的設計考量是可以共用的。