▌尼恩說在前面：
在40歲老架構師 尼恩的讀者社區(50 )中，最近有小夥伴拿到了一線互聯網企業如阿裡、滴滴、極兔、有贊、希音、百度、網易、美團的面試資格，遇到很多很重要的面試題：
微服務一定要用DDD，為什麼？
TDD也很流行，什麼是TDD？TDD和DDD 有何關系？
小夥伴沒有回答好，導致大廠機會沒了， 多麼可惜。
所以，這裡尼恩給大傢做一下系統化、體系化的梳理，使得大傢可以充分展示一下大傢雄厚的 “技術肌肉”，讓面試官愛到 “不能自已、口水直流”。
也一並把這個題目以及參考答案，收入咱們的 《尼恩Java面試寶典PDF》V164版本，供後面的小夥伴參考，提升大傢的 3高 架構、設計、開發水平。
《尼恩 架構筆記》《尼恩高並發三部曲》《尼恩Java面試寶典》的PDF，請到公號【技術自由圈】取
▌本文目錄：
- 尼恩說在前面
- 字節面試：微服務一定要用DDD，為什麼？
- 首先，說說微服務設計和拆分的困境
- 其次，說說解決困境的兩個方面
- 最後，說說DDD的理論指導價值和落地指導價值。
- 字節面試：TDD也很流行，什麼是TDD？
- 字節面試：TDD和DDD有何關系？
- 在問題DDD的前置問題
- 附1：說說，你對微服務是怎麼理解的？
- 附2：說說，微服務架構中的DRY是什麼？
- 附3：說說，設計微服務的最佳實踐是什麼？
- 尼恩說在後面
- 11個技術聖經 PDF▌字節面試：微服務一定要用DDD，為什麼？
▌首先，說說微服務設計和拆分的困境：
微服務解決大單體架構的的很多問題，比如擴展性、彈性伸縮能力、小規模團隊的敏捷開發等等。
好是好，但是微服務實踐過程中，大部分架構師遇到很多難題：
- 微服務的粒度應該多大呀？
- 微服務到底應該如何拆分和設計呢？
- 微服務的邊界應該在哪裡？
拆分微服務的時候，兩種情況：
- 有的顆粒度過大， 還是大單體
- 有的顆粒度過小，導致上線和運維工作量巨大。
很多“水貨架構師”，在拆分微服務的時候憑借感覺：簡單的把微服務理解為小單體，粗暴的把原來一個大單體包拆分為多個部署包，導致後期工程風險嚴重失控。從而陷入了微服務設計和拆分的困境。
▌其次，說說解決困境的兩個方面
微服務設計和拆分的困境，分成兩個方面：
- 理論面，缺乏一套系統的理論和方法指導。
- 落地面，缺乏一套可以參考的代碼骨架。
▌最後，說說DDD的理論指導價值和落地指導價值
DDD 就是這種不可多得的微服務設計和拆分的理論和方法指導。
DDD 指導了兩個層面的設計和建模：
- 宏觀層面：指導了微服務外部的建模，包括系統和系統之間， 微服務和微服務之間依賴關系的建模。
- 微觀層面：指導微服務內部的建模，包括 領域對象建模， 微服服務落地的各層關系的建模。
正因為如此，DDD現在非常火爆，有其巨大生產價值、經濟價值的， 絕不僅僅是一套概念那麼簡單。
各個大廠的大致情況是：
- 新項目都盡可能結合DDD進行設計建模、工程落地
- 老項目也在使用DDD進行從點到面的改造，以榨取軟件的最佳性能。
下面是尼恩在網上梳理到的案例， 實際上這僅僅就是冰山一角：
《阿裡大佬：DDD 落地兩大步驟，以及Repository核心模式》
《極兔面試：微服務爆炸，如何解決？Uber 是怎麼解決2200個微服務爆炸的？》
《阿裡大佬：DDD中Interface層、Application層的設計規范》
▌字節面試：TDD也很流行，什麼是TDD？
測試驅動開發是一種開發方法，其核心理念是在編寫實際代碼之前先編寫測試用例。
這些測試用例描述了所期望的代碼行為。
開發者根據這些測試用例來編寫代碼，以確保代碼通過所有測試並符合預期。
TDD的步驟通常是：
編寫測試用例 -> 運行測試（測試應該失敗） -> 編寫代碼 -> 再次運行測試（測試應該通過）。
常見的TDD框架包括JUnit（Java）、RSpec（Ruby）和unittest（Python）。
適合TDD這種模式的項目具備以下特點：
- 項目的需求必須足夠清晰，而且程序員對整個需求有足夠的了解。
- 項目的復雜度和依賴性要低。對於一個業務模型及其復雜、內部模塊之間的相互依賴性非常強的項目，采用TDD反而會得不嘗失，這會導致程序員在拆分接口和寫測試代碼的時候工作量非常大。另外，由於模塊之間的依賴性太強，我們在寫測試代碼的時候可能不采取一些橋接模式來實現，這樣勢必加大了程序員的工作量。
▌字節面試：TDD和DDD有何關系？
DDD如此之香，那麼多大廠對DDD如此癡迷， 背後 有深層次、根本性的原因
具體參見尼恩在《DDD學習聖經》為大傢深度總結的、下面的6點：
DDD 的一個根本能力，提升了 可測試性
DDD 為 TDD 的落地，提供很好的 基礎支撐 和 前置條件。
▌在問題DDD的前置問題
面試官在問DDD之前，先會問下 微服務。
這裡把這些前置問題，也給大傢簡歷梳理一下。
▌附1：說說，你對微服務是怎麼理解的？
微服務是由Martin Fowler大師提出的。微服務是一種架構風格，通過將大型的單體應用劃分為比較小的服務單元，從而降低整個系統的復雜度。
微服務，是一種架構風格，它將應用構建為一個小型自治服務的集合，。通俗地說，就像蜜蜂通過對蠟制的等邊六角形單元來構建它們的蜂巢。他們最初從使用各種材料的小單元開始，一點點的搭建出一個大型蜂巢。
微服務優點:
優勢說明獨立開發所有微服務都可以根據各自的功能輕松開發獨立部署根據他們所提供的服務，可以在任何應用中單獨部署故障隔離即使應用中的一個服務不起作用，系統仍然繼續運行混合技術棧可以用不同的語言和技術來構建同一應用程序的不同服務粒度縮放各個組件可根據需要進行擴展，無需將所有組件融合到一起
微服務缺點:
1、服務調用的復雜性提高了: 網絡問題、容錯問題、負載問題、高並發問題。
2、分佈式事務：盡量不要使用微服務事務。
3、測試的難度提升了。
4、運維難度提升:單體架構隻要維護一個環境，而到了微服務是很多個環境，並且運維方式還都不一樣。所以對部署、監控、告警等要求就會變得非常困難。
5、微服務拆分， 缺乏統一的標準，拆分不合理會導致後面 出現 內部混亂，從 "大泥球" 演變成 更多的 ”小泥球“
▌附2：說說，微服務架構中的DRY是什麼？
DRY（Don’t Repeat Yourself） ， 代表：不要重復自己。
DRY促進了重用代碼/代碼復用。
這意味著在多個地方不要重復同樣的代碼，而應該將它們封裝為庫或服務，以便在其他地方調用。
這種思想可以促進代碼的模塊化和可重用性，提高開發效率和質量。
所以，從微服務出發， 就演進出來了 技術中臺、數據中臺、業務中臺的架構
具體請參見尼恩 《DDD 學習聖經》
但是
DRY反過來導致緊耦合。
▌附3：說說，設計微服務的最佳實踐是什麼？
具體答案，請參見尼恩之前寫過的一個面試題答案：
美團面試：微服務如何拆分？原則是什麼？
註意其中的核心點：領域驅動原則，不數據驅動原則，也不是界面驅動原則
▌尼恩說在後面：
DDD 面試題，是非常常見的面試題。大傢面試的時候， 可以參考以上的內容去答，基本上 面試官會被你 震驚到、吸引到。
另外， 如果大傢在實操DDD的過程中，遇到困難，也可以找尼恩求助：
- 尼恩結合一個工業級的DDD實操項目，在第34章視頻《DDD的學習聖經》中，從理論面、落地面一起，給大傢做了徹底的介紹。
- 另外，在尼恩的一對一簡歷指導時，也指導DDD如何織入項目、應用到實操, 幫助大傢徹底穿透DDD。
此題目收入了最新的尼恩面試寶典，在面試之前，建議大傢系統化的刷一波 5000頁《尼恩Java面試寶典PDF》，並且在刷題過程中，如果有啥問題，大傢可以來 找 40歲老架構師尼恩。
最終，讓面試官愛到 “不能自已、口水直流”。offer， 也就來了。
▌11個技術聖經 PDF：
