幽默:如果微服務改名為業務元件會怎樣?- ntcoding
如果微服務將被稱為業務元件,這是否會將我們的思維轉向價值和業務戰略,而不是泛泛而談事物大小和Docker的大小?
眾說紛紜:
大多數人透過技術關注來組織一切。
我們一直在追逐技術銀彈。
一詞多義
可能部分是由於管理。經理有預算,要解決技術問題,他們必須獲得許可才能增加預算。因此,即使解決方案是眾所周知的,經過戰鬥考驗並隨著時間的流逝節省了資金,但最終的決定仍將是永遠堅持下去。
鑑於似乎業務世界中的許多人不太真正理解業務策略,所以我不確定這是否一定會帶來更好的結果。
其實就是這樣!命名會有所作為。業務元件意味著每個元件的單一業務中心目的,而不是規模,或者元件可以組合在一起或分開。“服務”是有缺陷的,因為它暗示了單個過程,“微”則意味著很小而不是單個上下文。
問題源於缺乏分散式計算/架構而非標籤方面的經驗和知識。
將體系結構或架構或邏輯與業務耦合總是讓我感到很奇怪。從業務關注到技術關注通常沒有明確的途徑。同樣,技術存在於“業務”(營利性企業)領域之外。
服務設計:1.以人為本:考慮所有受服務影響的人們的經驗。2.具有不同背景和職能的利益相關者應積極參與服務設計過程。3 .服務設計是一種探索性,自適應性和實驗性方法,會逐步實現。
相關文章
- 單體和微服務幽默新解圖片微服務
- 微服務元件 Sentinel(三)微服務元件
- 微服務元件 Sentinel(二)微服務元件
- 微服務元件 Sentinel(一)微服務元件
- 微服務呼叫元件 Feign微服務元件
- 幽默:最簡單的SpringBoot微服務程式碼Spring Boot微服務
- 微服務分散式事務元件 Seata(一)微服務分散式元件
- golang 微服務-基礎元件Golang微服務元件
- 【Alibaba】SpringCloudAlibaba微服務元件NacosSpringGCCloud微服務元件
- 幽默:ifelse代表業務邏輯
- dotnet core微服務框架Jimu ~ 會員註冊微服務微服務框架
- dotnet core微服務框架Jimu ~ 會員授權微服務微服務框架
- 微服務架構中分散式事務實現方案怎樣何取捨微服務架構分散式
- 微服務業務架構的探索微服務架構
- 理解Spring Cloud微服務框架核心元件SpringCloud微服務框架元件
- SpringBoot應用整合微服務元件NacosSpring Boot微服務元件
- 聊一聊微服務元件區別微服務元件
- 微服務 Spring cloud 各元件介紹微服務SpringCloud元件
- 微服務鏈路追蹤元件 SkyWalking微服務元件
- SpringCloud 微服務閘道器 Gateway 元件SpringGCCloud微服務Gateway元件
- 微服務時代元件化和服務化的抉擇微服務元件化
- 如果不用 Node.js 寫業務Node.js
- silky微服務業務主機簡介微服務
- 【微服務技術專題】Netflix動態化配置服務-微服務配置元件變色龍Archaius微服務元件AI
- Spring Cloud微服務基礎元件實戰SpringCloud微服務元件
- 微服務工程中,基礎元件應用微服務元件
- 單體 微服務 docker和k8s的邏輯幽默微服務DockerK8S
- 微服務03 微服務sentinel, springcloudgateway微服務SpringGCCloudGateway
- 幽默:什麼是業務邏輯程式碼?
- 微服務架構怎麼選?微服務架構
- 為什麼要使用微服務微服務
- 假設:如果意識也是客觀存在會怎樣?
- 如果搭建了智慧經營系統會怎麼樣?
- 如果攻擊者操控了 redirect_uri,會怎樣?
- 微服務2:微服務全景架構微服務架構
- 幽默:Ruby on Rails建立者DHH質疑無伺服器和微服務AI伺服器微服務
- 微服務業務生命週期流程管控引擎微服務
- 微服務元件之限流器與熔斷器微服務元件