許多人都認為，juval löwy是想讓服務無所不在，但他辯稱，微服務只是深思熟慮之後系統分解的邏輯結果。
\\ 在löwy設計和構建的系統中，每個類都是乙個服務，這是他在2007開創的一種方法，在《wcf服務程式設計》第四版中，他進一步闡述了這一方法。面向服務的應用程式更容易維護，因為業務邏輯和底層管道完全隔離，löwy已經克服了軟體開發平台的侷限，將這種隔離推廣到了系統的所有層面。
\\ infoq採訪了löwy，內容涉及軟體設計方法以及傳統方法中經常失敗的地方。
\\infoq：您提出「每個類作為乙個服務」的理念已經10多年了。是什麼讓您想到了這種方法？
\\
\\\juval löwy：一般來說，面向服務並不是一種質的飛躍——它只是漫長的軟體工程演進過程的下乙個步驟。例如，如果物件導向是乙個好主意，那麼你就不會停留在系統或子系統的層面上，並說那個粒度和物件一樣。恰恰相反，你會設法將物件的優勢盡可能地往下推，甚至建立基元物件。
\\ 服務是行業的一次嘗試，旨在將業務邏輯（這是客戶關心和購買的東西）和支撐業務邏輯的底層管道解耦，後者包括安全、啟用、同步、事務、錯誤處理、部署，等等。事實證明，管道占用了大部分的開發時間和工作，而開發人員往往在這方面做得並不好。借助微服務，你就可以選擇使用預先構建好的、現成的管道，這樣，你就可以在保持管道界限不變的同時，從標準管道中獲益。
\\ 不注意範圍（企業、系統、子系統、類）的話，管道會帶來麻煩，所以不難理解，要盡可能地利用服務所帶來的好處。由此可以得出最終的結論，整數或字串必須是服務。為什麼開發人員要考慮字串安全、整數同步等問題呢？
\\ 你所遇到的問題是，當時（如今）的開發平台沒有在這方面提供開箱即用的支援。不過，我解決了這個問題，並提出了一種增強技術，只要你願意，就可以在類的層面上使用服務，同時還可以保持現有的程式設計模型和常規類的總擁有成本不變。
\
infoq：過去十年中，「每個類作為乙個服務」的方法與soa模式相比怎麼樣，與我們如今看到的微服務運動相比又怎麼樣？
\\
\\\löwy：比較意味著對立或矛盾。但它們之間不存在那種關係。為了取得成功，你應該在我十年前提出的粒度上使用服務。這恰恰是合理的設計。
\\ 你的身體不是個大問題。但只有乙個巨大單體服務的系統是不具可維護性的，它充斥著缺陷，會帶來痛苦。沒有什麼可以重用和擴充套件。
\\ 為外界提供乙個「大」服務或功能沒什麼錯，但實現方式應該是通過整合微服務。順便說一下，這是個通用的設計規則：功能一值都是整合出來的，而不是實現出來的。任何東西都是這樣的，如馬、汽車、平板電腦、工廠，等等。汽車有乙個重要的功能，就是可以把你從a地點帶到b地點，但汽車並沒有提供開箱即用的實現。這個功能是通過整合汽車的內部元件、司機、燃料和公路提供的。
\
infoq：如何正確地分解系統？那與傳統的設計方法有什麼不同？
\\
\\\löwy：事實證明，大部分人都是根據功能或領域來分解設計的。因此，如果需要完成a、b、c，他們就會有乙個a服務、乙個b服務、乙個c服務，或者他們會找個地方（領域）安置a或b。這種方法的問題是，隨著時間推移（不用太長時間），需要做的東西會發生變化，其結果就是，設計需要修改。當設計需要修改時就非常痛苦了。
\\ 結論是，你永遠不應該針對需求（或功能，或用例，或使用者故事）進行設計。相反，你必須識別出構建塊的最小集合，如果你願意，可以稱它們為微服務，你可以把它們組合在一起滿足任何需求：現在的和未來的，已知的和未知的。關於如何做到這一點，有乙個完善的過程。
\\ 正確的設計方法是確定出容易變化的部分，把它們封裝進（微）服務。然後，你就可以將需要的行為實現為那些服務之間的互動。新需求只不過意味著一種不同的服務互動，而不是一種不同的分解，所以現在，當需求變化時，設計無需修改。
\\ 此外，由於分解是根據容易變化的部分進行的，當變化發生時，只需在乙個地方處理它，這樣，你就遏制了變化。使用功能或領域分解，當變化發生時，它影響的不只乙個地方，所以你就最大化了變化的影響，讓它成為最糟糕的架構設計方法。
\\ 微服務極大地增強了這種分解方法，因為服務就是要簡化互動和整合。此外，在大部分軟體系統中，容易變化的部分都很典型，所以，你可以以此為起點。這些部分也會有典型的互動模式，所以，一旦識別了出來，設計就會非常快速正確地收斂。
\
infoq：在基於易變性進行分解之後，開發過程該如何適應乙個高度模組化的系統構建方法？
\\
\\\löwy：你要設計和構建服務，但也要構建裝配它們的工廠。當你想要生產汽車時，你首先要設計汽車的各個元件（變速箱、引擎、油幫浦、座椅，等等），但你還必須設計裝配線來將這些零件組裝在一起。從設計的角度看，它甚至比零件或汽車本身的設計更具挑戰性。任何人都可以設計汽車油幫浦。設計一種可以滿足數百種汽車的油幫浦，或者設計一條可以組裝很多不同汽車的裝配線，可不是一件簡單的事情。
\\ 在軟體領域，你要設計微服務（零件）和專案（裝配線）。這不是偶然或意外。你不會偶然建立一座工廠。借助經驗與實踐，你還可以引入多個管道，如服務、單元測試、整合等，提公升工廠的生產能力。你所做的一切都是遵循一套完善的工程指南，而後者來自於容易變化的部分之間特定的互動模式。
\\ 其結果是超級敏捷，因為使用那些微服務，你可以非常快地準備好新特性和行為。借用敏捷術語來說，你使用已經構建的微服務實現了使用者故事，理論上不需要任何新**。在一座汽車工廠中，實際的生產非常少——零件整個地到達工廠，他們只是整合它們。
\
關於受訪者
\\ juval löwy是idesign的建立者，同時也是一名專門研究系統和專案設計的大師級軟體架構師。löwy對全球數百名架構師進行過指導，分享他在架構、專案設計、開發過程和技術方面的觀點、技巧和突破性創新。löwy是微軟矽谷地區的區域負責人，參與過微軟內部c#、wcf及相關技術的戰略設計評審。löwy經常在各種重大的國際軟體開發大會上發表演講。他已經出版了多本暢銷書，並發表了大量的文章。作為世界上最頂尖的專家和行業領導者之一，微軟授予他「軟體傳奇」稱號。你可以通過他的**和他取得聯絡。
\\檢視英文原文：juval löwy: why every class should be a service
Juval L wy 為什麼每個類都應該是乙個服務
許多人都認為，juval l wy是想讓服務無所不在，但他辯稱，微服務只是深思熟慮之後系統分解的邏輯結果。在l wy設計和構建的系統中，每個類都是乙個服務，這是他在2007開創的一種方法，在 wcf服務程式設計 第四版中，他進一步闡述了這一方法。面向服務的應用程式更容易維護，因為業務邏輯和底層管道完...
Juval L wy 為什麼每個類都應該是乙個服務
許多人都認為，juval l wy是想讓服務無所不在，但他辯稱，微服務只是深思熟慮之後系統分解的邏輯結果。在l wy設計和構建的系統中，每個類都是乙個服務，這是他在2007開創的一種方法，在 wcf服務程式設計 第四版中，他進一步闡述了這一方法。面向服務的應用程式更容易維護，因為業務邏輯和底層管道完...
Juval L wy 為什麼每個類都應該是乙個服務
許多人都認為，juval l wy是想讓服務無所不在，但他辯稱，微服務只是深思熟慮之後系統分解的邏輯結果。在l wy設計和構建的系統中，每個類都是乙個服務，這是他在2007開創的一種方法，在 wcf服務程式設計 第四版中，他進一步闡述了這一方法。面向服務的應用程式更容易維護，因為業務邏輯和底層管道完...