層應該在代碼結構中可視化嗎？

Question

在閱讀了 Bob 叔叔的 Clean Architecture 之后，我一直在思考尖叫架構的概念以及關於組織代碼的最后一章。

我通常喜歡使用結構中存在的層來輕松地將代碼放置在正確的層中，但我也看到了按特征划分的好處。

我最近開始從事的一個大型項目根本沒有顯示層結構，您必須查看架構文檔才能了解 java package 位於哪個層。 該項目使用 OSGI 包。

該項目由大量開發人員成功完成，並且似乎運行良好，但我不禁感到結構令人困惑且難以使用，並且在創建新功能時需要架構師參與以確保層是堅持。

我的問題是這是否常見，以及不以某種方式包含層結構的原因是什么？

例如，做這樣的事情似乎是一個干凈的解決方案。 https://blog.ttulka.com/package-by-component-with-clean-modules-in-java

Answer 1

我的問題是這是否常見，以及不以某種方式包含層結構的原因是什么？

問題是“代碼的結構會給你帶來什么好處嗎？” 這取決於您使用的編程語言。

例如，在 Java 中，您有訪問修飾符public 、 protected 、 private和 default（無修飾符）。 默認和protected允許在同一個 package 內訪問。 protected的還允許訪問其他地方的擴展類。 這意味着如果您使用這個修飾符，您可以控制類、方法和字段的可見性。

控制對類和 class 成員的訪問可以讓您的生活更輕松。 我經常看到public修飾符被廣泛使用。 這會導致一些問題：

1. 開發人員經常在類之間引入從未打算過的依賴關系，但引入它們是因為您可以做到。
2. 如果一切都是public的，IDE 不能很好地支持你。 開發人員通常使用某種自動完成功能，或者在編寫代碼時使用類型搜索。 如果一切都是public的，那么一切都可以從任何地方訪問。 由於 IDE 將列出所有可訪問的選項，因此它會顯示一長串條目。 因此， public不會讓生活更輕松。 同樣可悲的是，由於這種情況，開發人員經常引入更多的包來組織代碼，因此認為他們做得更好，從而使情況變得更糟。

西蒙布朗在清潔架構書中寫了“缺失的章節”一章，他說：

Java 中的訪問修飾符並不完美，但忽略它們只是自找麻煩。 將 Java 類型放入打包的方式實際上可以在適當應用 Java 的訪問修飾符時對這些類型的可訪問性（或不可訪問性）產生巨大影響。 如果我帶回包並標記（通過圖形淡化）可以使訪問修飾符更具限制性的那些類型，那么圖片變得非常有趣。

該圖取自干凈的架構書，章節“缺失的章節”，第 318 頁。

現在您可以看到包裝類型之間的差異。 如果一切都是public的，那么它們實際上都是平等的。

更多信息可以在這里找到：

• 模塊化單體，Simon Brown，GOTO 2018
• api 的分離和實施，René Link，2012 年 2 月