很多人都在談論那件事，但實際上只有少數人在談論
有時會有人提到這個詞。 在最多樣化的環境中。 這個詞曾被用來表達許多不同的事物，當一個單詞可以表達任何含義時，它最終就意味著什么。 在本文中，我經過大量研究后，以迄今為止最精確的方式解釋了我對軟件體系結構的看法。
> A library's architecture doesn't define how the books are going to be organized
作為軟件制作者，我們將根據目前對編程以及應用程序業務領域的了解，盡力而為地編寫代碼。
隨著時間的流逝，我們不僅學到了編程技術，而且學到了業務領域的特殊性和特征，而且學到了越來越多的東西。
趨勢在變化，新的編程技術不斷涌現，其中一些在市場上越來越受關注。 隨著更多功能添加到軟件中，業務領域也不斷發展和變化。
因此，我們編寫的代碼似乎正在慢慢衰減，因為我們在編寫時沒有掌握新知識。 每次查看較舊的代碼時，我們都會更加確信它不再反映出應該解決的最佳模型。
> Code decaying over time
這是正常的。 它從項目開始就發生，并將一直持續到結束。 軟件之所以軟是因為它被更改了。 重構。 實驗過已調整。 已更正。 遞增。
但是更改此代碼并非易事，因為在大多數情況下，系統很復雜。 變更的影響并不總是很明顯。 我們害怕破壞某些東西而感到震驚。 這就是我們編寫自動化測試的原因。 能夠無所畏懼地更改軟件。 為了能夠重寫，調整，試驗，修復。
> Automated tests to measure the impact of change
不僅要知道軟件是否可以運行。 如果我們永遠都不會改變該系統，那么經過良好的手動測試將非常擅長于確保一個版本能夠正常工作。 也許比自動測試更好，因為手動測試是強制性的端到端，并且還可以捕獲UX和業務領域中無法預料的問題。
事實證明，編寫自動化測試不足以使我們的軟件易于更改。 如果代碼與實現細節（如UI，數據庫以及與其他系統的通信）過于耦合，則代碼中的任何更改都將受到這些外部因素強加給我們代碼的固有建模的約束。
對業務規則建模方式的任何更改都將在多個自動化測試和實施詳細信息中進行更改。 要改善業務規則中變量的名稱，就是要使其在數據庫，屏幕或其他位置也進行更改。 較大的變化，結構性變化會放松我們的脊柱。
> When one change causes others
這就是創建架構的原因。 在對系統建模時，架構并不是要遵循的秘訣。 這不是術語。 這不是將業務規則組織到類或方法中的方法。 架構不是DDD [1]。
架構是將我們的代碼與外部因素隔離開來的方法，因此我們可以自由地以我們目前認為最好的方式對問題的解決方案進行建模和重新建模。 然后重新進行建模。 然后再次。
當今最著名的架構之一是清潔建筑：
在本文中，鮑勃叔叔似乎確實提供了秘訣，術語以及將業務規則組織到類和方法中的方法。 但是，如果仔細閱讀，就會發現所有架構的目標都是實現所謂的獨立性，即所謂的自由。
自由學習和改造系統而不會破壞一切。 自由清理代碼。
這就是為什么有用例（交互器）的原因。 它們代表用戶可以在系統中執行的操作。 它們是UI和應用程序之間的通信橋梁。 這就是為什么有Presenters的原因，當涉及到一些額外的處理來呈現信息時，Presenter會從應用程序返回到UI。 它們是外殼的一部分，它們可以不同地命名，也可以具有其他形式，只要它們能夠發揮其隔離作用即可。
從那里開始，不應強加嚴格的規則。 這才是重點。 不受規定的約束。 我們已經編寫了所有測試，所有用例和演示者都存在，因此我們擁有更大的自由度來定義實體的狀態以及它們的行為方式。
> Once the library's architecture is ready, we can organize the books as we please
因此，我們自己可以定義它們是否應該是函數，類，應該具有多少種方法。 如果它們將在網關（存儲庫）中實例化，則它們將在構造函數或方法中接收數據。 以及任何其他建模方式。
每個域都有其特殊性。 規則不適合，原則適合。 每個原理都將以給定的方式應用于每個領域。 一切都取決于。 但是要在這一點上前進，我們需要習慣于重新思考。 也許回去做幾片kata或dojos。
忘記規則，忘記模式……解決問題的最簡單方法是什么？
忘記屏幕，忘記數據庫…解決教授提出的大學挑戰的最簡單算法是什么？
忘記用例，忘記體系結構…編寫測試，查看失敗，編寫可能通過的最少代碼，然后進行重構。
忘了上課，忘了界面…更具可讀性的是什么？ 對于剛開始在公司工作的新手來說，最容易理解的是什么？
忘記模式，忘記繼承…我放置此代碼的軟件包是否一致？ 使用此規則的任何人都容易找到它嗎？
當然，我們將使用UI，數據庫，用例和模式，類，接口和繼承。 但是這些東西都是用來幫助我們為解決問題的最簡單代碼建模的工具。
域的每個部分都有不同的問題。 即使它們看起來都像相同的CRUD。 系統的一部分將需要一個在構造函數中具有數據的實體，另一部分將需要一個在網關內部生成的實體。 另一部分將需要其中包含許多規則的網關。 另一個將有一個僅由其他用例使用的用例，另一個將使它們全部內聯。
但是問題更重要：此代碼是目前最簡單的代碼嗎？ 就是這樣，因為過一會我們會學到更多，并將此代碼更改為更好的代碼。
[1]《域驅動設計》一書探討了一些概念，這些概念有助于將應用程序與外部因素隔離開來，但目標是以與業務領域一致的方式對業務規則進行建模-這確實非常重要，而另一個主題是 文章-并沒有過多地關注獨立性和自由性。
(本文翻譯自Caio Andrade的文章《What Exactly Is Software Architecture?》，參考：https://medium.com/swlh/what-exactly-is-software-architecture-c1c67d1213f3)
