ขนาดวิดีโอ: 1280 X 720853 X 480640 X 360
แสดงแผงควบคุมโปรแกรมเล่น
เล่นอัตโนมัติ
เล่นใหม่
Clean Architecture : 無瑕的程式碼 - 整潔的軟體設計與架構篇，封底語錄 :+ 架構代表了塑造系統的「重要」設計決策，有多「重要」則是由因應變化的成本來橫量的。 - Grady Booch，軟體大師+ 架構是你希望在專案早期就能得到的決定，但你並不一定能比其他任何時候更容易得到它們。 - Ralph Johnson，GoF+ 架構是一個假設，需要透過實作和度量來證明。 - Tom Gilb軟體架構的「設計」方法，非常相似於「策略」的規劃。推薦觀看另外一部，專門講述「策略」的書籍知識分享:th-cam.com/video/Ntp-bWvkNZE/w-d-xo.html(如何規劃策略、解決問題 ? 好策略 • 壞策略 : 策略公式 + 9 種策略力量 | 面對 x 挑戰 | 制定解決方法的方法)「策略」中的其中一章節，組織容易受到「慣性」與「亂度」兩種力量影響，導致運作得沒有效率。對映到「架構設計」，程式也同樣是因為這兩種力量，導致結構發散、難以調整。我認為，「架構設計」與「規劃策略」都是一種大局觀的思考方式，可以運用於公事的「專案執行」，也可以運用於私事的「職場規劃、理財投資」。如果能夠學會解決人生大問題的方法，那麼要解決軟體架構設計的小問題，肯定不在話下。
ㄧ聽就懂講得很清楚 感謝您 🙏
這是對知識分享者最好的肯定👍感謝你的反饋😀
感到慚愧，看完後只覺得似懂非懂的，請問有沒有什麼方面的資料能幫助我對這塊的瞭解?前面不少人都推薦了一些書藉，卻不知道該怎麼選擇
「無瑕的程式碼 - 架構篇」是我主要軟體架構知識來源，這本雖然還有很多地方看不懂，但一些簡單的概念卻是受益無窮，例如 : 如何區分高層級與低層級模組的等級，是使用距離 I/O 的遠近決定，越遠代表層級越高、越近代表層級越低。(就如同公司的高階主管，不是外人想見就可以見的。)類似的架構概念還有很多 ~不過 SOLID 的概念，我也是在第二份工作的技術分享時才第一次接觸。 (不用慚愧，大家都曾經似懂非懂過 XD)而且如果我沒有做這個影片的話，其實對原則的理解也是模糊、不太確定。😅
影片非常容易理解，但其實這些名詞縮寫跟解釋我都不知道就是了. 但裡頭描述的所有行為模式卻已經是行之有年的習慣.
把共用的東西放在DDD 的infrastructure layer 並不恰當。infra layer 的主要目的並不是這樣。一般來說共用的東西應考慮另開一個bounded context。在OCP 說盡量不修改 domain layer 就也很欠準確。domain 層是主要的 business logic。OCP 應著眼於domain layer 的設計，而不是把domain layer 當成是「盡量不修改」的東西。
不是說共用的東西都放在 infra layer，我的用詞是「真正由所有角色 共用的資源」以及「基礎設施層 負責的是整個系統對象」關鍵字是「真正」與「所有」，我過去維護過的其中一個專案就是開一個 common (常見)的套件，然後把所有的 util 都放進去，不管這個 util 負責的業務跨了多少層級。(這是錯誤作法，但用詞是以此延伸)系統中「真正所有角色」共用的資源，實際上相對少見，個別角色間共用資源相對常見，我知道你的意思應該是 domain layer 中，近一步的劃分區塊，而不是跨層級跑到 infra layer 👌關於 OCP 確實如你所說的，應該是「設計」成「擴展是開放 修改是封閉」，而不是開發時要怎麼做這部分我在「什麼是 OCP ? 」有提到更多的應該是著重於「設計」的意思，因此在「 怎麼做 OCP ? 」就沒有再重複提及。但我依據「離 I/O 的遠近，決定系統層級」以及 耦合性三大原則中的「穩定依賴原則 SDP」我認為 domain layer 中的 business logic 是系統的核心，既然是核心，特性就應該是穩定、不容易被修改。關於領域驅動設計(DDD) 以及一些其他概念，下面的影片會有相對完整的補充 :領域驅動設計 - th-cam.com/video/mducM_tUUEY/w-d-xo.html元件耦合性原則 - th-cam.com/video/cSQY0rA7FPU/w-d-xo.html元件內聚性原則 - th-cam.com/video/wRyzCktcbNQ/w-d-xo.html歡迎建議與補正 ~ 😀( DDD 領域驅動的知識，大部分是來自於 Spring Cloud 微服務的書籍。細節的部分會有遺漏，例如 bounded context 的名詞就沒有再書籍中出現過，之後有 DDD 更精確的認知，我會再補充說明 )
讲得好棒，我可以在我文章里面引用你的视频，以及截图吗
可以呦，沒有問題👌
講得很好耶，而且也有注意到 Uncle bob 更新後的 SRP 規則（加了角色），沒把角色加進去看這個原則就很容易各自解讀這麼淺顯易懂一定要拿來推廣 👍
歡迎推廣 😀工作室目前還是 1.5 人工作室，總有一天會拉人組團隊，到時直接拿來當前置的教育訓練。如果可以成為各家資訊公司或開發部門的參考資訊，是莫大的榮幸。
很棒的分享，👍👍👍👍👍這篇內容基本上用最簡單的方法，解釋這些原則，至於七大、八大原則，大多是這五個原則在擴展出來的東西當初在唸時還有 "最少知識原則(也叫好萊塢原則:出自深入淺出設計模式)""少用繼承多用組合原則(出自 大話設計模式(好像是))"其實都是派生出來的原則當初無瑕的程式碼實在是看不懂，所以我去看另一本 我的程式碼會說話 他這本寫的比較攏統直到看到 設計模式與遊戲開發的完美結合 (我是遊戲業的)才正式理解程式原則是什麼，這邊讓我又再複習一次，並且更加理解👍👍👍👍👍👍👍👍👍
感謝肯定 !書籍後面也有個概念很像是「少用繼承多用組合原則」，不過書中沒有出現這個名詞。想我當初還在公司跟前輩爭論，共用的 Util 到底要用繼承第三方的 Util 庫好，還是不用繼承，全部封裝起來。 (我是封裝派)原來有個直接的原則建議。寫這些原則的解釋時，也是很怕講錯 (誤人子弟)，所以我都會偷偷強調「個人理解」、「講錯可以揪錯」，寫得是可以說服我的理由，但其他人我就不敢肯定。有正面的反饋，覺得底氣更足了，非常感謝 😀
@@rhxs020 個人認為說 繼承以及封裝都是好方法，但有問過前輩或是你自己為什麼要用這樣的方法嗎? 是因為習慣嗎? 還是是因為這樣的code 很適合這樣的子的方法？我認為的程式＂設計＂不應該會被現有的方法所綁住～
@阿團 共用的 Util 用繼承的方式實作，原因很純粹，就是因為「簡單」。繼承後把新的功能加在Util 即可。而我傾向用封裝的原因主要是在 Util 的「名稱」與「功能定義」上例如 : FileUtil 是第三方元件庫，繼承後叫做 CustomFileUtil (當時真的就是 Custom 開頭)，目的是收羅各種的 File 操作的功能。先不說 Custom 的命名本來就不應該出現，而繼承又是一種「強依賴」關係，這種實作的 Util 更應該被命名為「FileUtilPlus」之類的。(也就是說，這個新的 Util 是第三方 Util 的升級版，有更多的功能。但是不是就要當成共用的 Util 有待商確)共用的 Util 用封裝，是因為對內可以統一接口，客戶端的開發者不應該還要去熟悉第三方庫的 API，他只要知道這個 Util 有什麼功能即可。而維護這個 Util 的工程師，接口已經定義好，但實作可以任意切換。如果哪天 第三方元件庫有 bug 或 更新，或者是想直接換一個元件庫 ; 這裡的任何改動，只要能滿足接口定義，都不會影響到客戶的程式運作。反過來說，用繼承的話，那就是客戶端的模組跟服務端的 Util 締結神聖誓言，一輩子不分開。繼承的 Util 要換那就是兩個都要一起動，而且都叫做「共用」，影響面就超廣，所以基本上不可能更動。我在查相關資料時，發現兩者是可以共存的，FileUtilPlus 定義為「第三方的增強版」，然後被定義為「共用」的 Util 再將它封裝起來，如此兩者，既能滿足名稱與定義的正確性，也能夠保留後續修改擴增的彈性。以上，是我的個人想法，主要是以架構方面，保留彈性為主。但以實務面而言，如果就只是個收益不高的小專案，不能改就不能改，後續的維護者也不知道是不是我們公司，其實使用繼承也不是不能接受。(一不小心就打了好多字，同樣感謝你的反饋 😀 )
這東西很棒，不過在大公司，有些主管就無法接受這種概念。尤其ASP net有一派邏輯很奇怪，就是程式掛掉就直接讓他死掉，連背景運作都這樣寫，從不考慮資料類型與高低層次...客戶就會直接跟你翻臉，尤其背景運作，一旦因為一點小事延宕停止，該做的事情就跟著全停了
感謝肯定 ! 😀我以前有遇過，雖然是大公司，卻是小部門。人事規章的什麼流程都很完善，但軟體開發的流程就亂七八糟。專案 Delay，工程師一條龍，兼客服、修 Bug、完成後直接回報 (往事不堪回首 😅 )
謝謝提供輕鬆容易瞭解的內容
挖操 講得很好欸 實屬牛逼🔥🔥🔥站在更高的維度去理解原則，更貼近本質看完後深感我之前的理解層次只是蜻蜓點水感謝您 之後再找時間看 Clean Architecture 謝謝無私分享 👍🏼👍🏼 被震撼到了 🙇♂🙇♂
感謝 ~ SOLID 如果在面試時被問到，除了說明概念，還可以舉幾個實際案例，說不定面試官都沒有你理解的深刻 😀
讲的真好
目前看SOLID講最好的
講得真的超級好! 謝謝😊
👍 👍 感謝肯定 😀
感謝大大
感謝肯定 😀
Clean Architecture : 無瑕的程式碼 - 整潔的軟體設計與架構篇，封底語錄 :
+ 架構代表了塑造系統的「重要」設計決策，有多「重要」則是由因應變化的成本來橫量的。 - Grady Booch，軟體大師
+ 架構是你希望在專案早期就能得到的決定，但你並不一定能比其他任何時候更容易得到它們。 - Ralph Johnson，GoF
+ 架構是一個假設，需要透過實作和度量來證明。 - Tom Gilb
軟體架構的「設計」方法，非常相似於「策略」的規劃。
推薦觀看另外一部，專門講述「策略」的書籍知識分享:
th-cam.com/video/Ntp-bWvkNZE/w-d-xo.html
(如何規劃策略、解決問題 ? 好策略 • 壞策略 : 策略公式 + 9 種策略力量 | 面對 x 挑戰 | 制定解決方法的方法)
「策略」中的其中一章節，組織容易受到「慣性」與「亂度」兩種力量影響，導致運作得沒有效率。
對映到「架構設計」，程式也同樣是因為這兩種力量，導致結構發散、難以調整。
我認為，「架構設計」與「規劃策略」都是一種大局觀的思考方式，
可以運用於公事的「專案執行」，也可以運用於私事的「職場規劃、理財投資」。
如果能夠學會解決人生大問題的方法，那麼要解決軟體架構設計的小問題，肯定不在話下。
ㄧ聽就懂
講得很清楚 感謝您 🙏
這是對知識分享者最好的肯定👍
感謝你的反饋😀
感到慚愧，看完後只覺得似懂非懂的，請問有沒有什麼方面的資料能幫助我對這塊的瞭解?
前面不少人都推薦了一些書藉，卻不知道該怎麼選擇
「無瑕的程式碼 - 架構篇」是我主要軟體架構知識來源，
這本雖然還有很多地方看不懂，但一些簡單的概念卻是受益無窮，
例如 :
如何區分高層級與低層級模組的等級，是使用距離 I/O 的遠近決定，越遠代表層級越高、越近代表層級越低。
(就如同公司的高階主管，不是外人想見就可以見的。)
類似的架構概念還有很多 ~
不過 SOLID 的概念，我也是在第二份工作的技術分享時才第一次接觸。 (不用慚愧，大家都曾經似懂非懂過 XD)
而且如果我沒有做這個影片的話，其實對原則的理解也是模糊、不太確定。😅
影片非常容易理解，但其實這些名詞縮寫跟解釋我都不知道就是了. 但裡頭描述的所有行為模式卻已經是行之有年的習慣.
把共用的東西放在DDD 的infrastructure layer 並不恰當。infra layer 的主要目的並不是這樣。一般來說共用的東西應考慮另開一個bounded context。
在OCP 說盡量不修改 domain layer 就也很欠準確。domain 層是主要的 business logic。OCP 應著眼於domain layer 的設計，而不是把domain layer 當成是「盡量不修改」的東西。
不是說共用的東西都放在 infra layer，
我的用詞是「真正由所有角色 共用的資源」以及「基礎設施層 負責的是整個系統對象」
關鍵字是「真正」與「所有」，我過去維護過的其中一個專案就是開一個 common (常見)的套件，
然後把所有的 util 都放進去，不管這個 util 負責的業務跨了多少層級。(這是錯誤作法，但用詞是以此延伸)
系統中「真正所有角色」共用的資源，實際上相對少見，個別角色間共用資源相對常見，
我知道你的意思應該是 domain layer 中，近一步的劃分區塊，而不是跨層級跑到 infra layer 👌
關於 OCP 確實如你所說的，應該是「設計」成「擴展是開放 修改是封閉」，而不是開發時要怎麼做
這部分我在「什麼是 OCP ? 」有提到更多的應該是著重於「設計」的意思，因此在「 怎麼做 OCP ? 」就沒有再重複提及。
但我依據「離 I/O 的遠近，決定系統層級」以及 耦合性三大原則中的「穩定依賴原則 SDP」
我認為 domain layer 中的 business logic 是系統的核心，既然是核心，特性就應該是穩定、不容易被修改。
關於領域驅動設計(DDD) 以及一些其他概念，下面的影片會有相對完整的補充 :
領域驅動設計 - th-cam.com/video/mducM_tUUEY/w-d-xo.html
元件耦合性原則 - th-cam.com/video/cSQY0rA7FPU/w-d-xo.html
元件內聚性原則 - th-cam.com/video/wRyzCktcbNQ/w-d-xo.html
歡迎建議與補正 ~ 😀
( DDD 領域驅動的知識，大部分是來自於 Spring Cloud 微服務的書籍。
細節的部分會有遺漏，例如 bounded context 的名詞就沒有再書籍中出現過，
之後有 DDD 更精確的認知，我會再補充說明 )
讲得好棒，我可以在我文章里面引用你的视频，以及截图吗
可以呦，沒有問題👌
講得很好耶，而且也有注意到 Uncle bob 更新後的 SRP 規則（加了角色），沒把角色加進去看這個原則就很容易各自解讀
這麼淺顯易懂一定要拿來推廣 👍
歡迎推廣 😀
工作室目前還是 1.5 人工作室，總有一天會拉人組團隊，到時直接拿來當前置的教育訓練。
如果可以成為各家資訊公司或開發部門的參考資訊，是莫大的榮幸。
很棒的分享，👍👍👍👍👍
這篇內容基本上用最簡單的方法，解釋這些原則，
至於七大、八大原則，大多是這五個原則在擴展出來的東西
當初在唸時還有
"最少知識原則(也叫好萊塢原則:出自深入淺出設計模式)"
"少用繼承多用組合原則(出自 大話設計模式(好像是))"
其實都是派生出來的原則
當初
無瑕的程式碼實在是看不懂，
所以我去看另一本 我的程式碼會說話
他這本寫的比較攏統
直到看到 設計模式與遊戲開發的完美結合 (我是遊戲業的)
才正式理解程式原則是什麼，
這邊讓我又再複習一次，並且更加理解
👍👍👍👍👍👍👍👍👍
感謝肯定 !
書籍後面也有個概念很像是「少用繼承多用組合原則」，不過書中沒有出現這個名詞。
想我當初還在公司跟前輩爭論，共用的 Util 到底要用繼承第三方的 Util 庫好，還是不用繼承，全部封裝起來。 (我是封裝派)
原來有個直接的原則建議。
寫這些原則的解釋時，也是很怕講錯 (誤人子弟)，
所以我都會偷偷強調「個人理解」、「講錯可以揪錯」，寫得是可以說服我的理由，但其他人我就不敢肯定。
有正面的反饋，覺得底氣更足了，非常感謝 😀
@@rhxs020 個人認為說 繼承以及封裝都是好方法，但有問過前輩或是你自己為什麼要用這樣的方法嗎?
是因為習慣嗎? 還是是因為這樣的code 很適合這樣的子的方法？
我認為的程式＂設計＂不應該會被現有的方法所綁住～
@阿團
共用的 Util 用繼承的方式實作，原因很純粹，就是因為「簡單」。繼承後把新的功能加在Util 即可。
而我傾向用封裝的原因主要是在 Util 的「名稱」與「功能定義」上
例如 :
FileUtil 是第三方元件庫，繼承後叫做 CustomFileUtil (當時真的就是 Custom 開頭)，目的是收羅各種的 File 操作的功能。
先不說 Custom 的命名本來就不應該出現，而繼承又是一種「強依賴」關係，這種實作的 Util 更應該被命名為「FileUtilPlus」之類的。
(也就是說，這個新的 Util 是第三方 Util 的升級版，有更多的功能。但是不是就要當成共用的 Util 有待商確)
共用的 Util 用封裝，是因為對內可以統一接口，客戶端的開發者不應該還要去熟悉第三方庫的 API，他只要知道這個 Util 有什麼功能即可。
而維護這個 Util 的工程師，接口已經定義好，但實作可以任意切換。
如果哪天 第三方元件庫有 bug 或 更新，或者是想直接換一個元件庫 ; 這裡的任何改動，只要能滿足接口定義，都不會影響到客戶的程式運作。
反過來說，用繼承的話，那就是客戶端的模組跟服務端的 Util 締結神聖誓言，一輩子不分開。
繼承的 Util 要換那就是兩個都要一起動，而且都叫做「共用」，影響面就超廣，所以基本上不可能更動。
我在查相關資料時，發現兩者是可以共存的，
FileUtilPlus 定義為「第三方的增強版」，然後被定義為「共用」的 Util 再將它封裝起來，
如此兩者，既能滿足名稱與定義的正確性，也能夠保留後續修改擴增的彈性。
以上，是我的個人想法，主要是以架構方面，保留彈性為主。
但以實務面而言，如果就只是個收益不高的小專案，不能改就不能改，
後續的維護者也不知道是不是我們公司，其實使用繼承也不是不能接受。
(一不小心就打了好多字，同樣感謝你的反饋 😀 )
這東西很棒，不過在大公司，有些主管就無法接受這種概念。
尤其ASP net有一派邏輯很奇怪，就是程式掛掉就直接讓他死掉，連背景運作都這樣寫，從不考慮資料類型與高低層次...客戶就會直接跟你翻臉，尤其背景運作，一旦因為一點小事延宕停止，該做的事情就跟著全停了
感謝肯定 ! 😀
我以前有遇過，雖然是大公司，卻是小部門。
人事規章的什麼流程都很完善，但軟體開發的流程就亂七八糟。
專案 Delay，工程師一條龍，兼客服、修 Bug、完成後直接回報 (往事不堪回首 😅 )
謝謝提供輕鬆容易瞭解的內容
挖操 講得很好欸 實屬牛逼🔥🔥🔥
站在更高的維度去理解原則，更貼近本質
看完後深感我之前的理解層次只是蜻蜓點水
感謝您 之後再找時間看 Clean Architecture
謝謝無私分享 👍🏼👍🏼 被震撼到了 🙇♂🙇♂
感謝 ~ SOLID 如果在面試時被問到，除了說明概念，還可以舉幾個實際案例，說不定面試官都沒有你理解的深刻 😀
讲的真好
目前看SOLID講最好的
講得真的超級好! 謝謝😊
👍 👍 感謝肯定 😀
感謝大大
感謝肯定 😀