聞數(shù)起舞 2020-07-14 07:31:54

很多人都在談?wù)撃羌?，但?shí)際上只有少數(shù)人在談?wù)?/p>

有時(shí)會有人提到這個詞。 在最多樣化的環(huán)境中,。 這個詞曾被用來表達(dá)許多不同的事物,，當(dāng)一個單詞可以表達(dá)任何含義時(shí)，它最終就意味著什么,。 在本文中,，我經(jīng)過大量研究后，以迄今為止最精確的方式解釋了我對軟件體系結(jié)構(gòu)的看法,。

作為軟件制作者,，我們將根據(jù)目前對編程以及應(yīng)用程序業(yè)務(wù)領(lǐng)域的了解，盡力而為地編寫代碼,。

隨著時(shí)間的流逝,，我們不僅學(xué)到了編程技術(shù)，而且學(xué)到了業(yè)務(wù)領(lǐng)域的特殊性和特征,，而且學(xué)到了越來越多的東西,。

趨勢在變化，新的編程技術(shù)不斷涌現(xiàn),，其中一些在市場上越來越受關(guān)注,。 隨著更多功能添加到軟件中，業(yè)務(wù)領(lǐng)域也不斷發(fā)展和變化,。

因此,，我們編寫的代碼似乎正在慢慢衰減，因?yàn)槲覀冊诰帉憰r(shí)沒有掌握新知識,。 每次查看較舊的代碼時(shí),，我們都會更加確信它不再反映出應(yīng)該解決的最佳模型。

這是正常的,。 它從項(xiàng)目開始就發(fā)生,，并將一直持續(xù)到結(jié)束。 軟件之所以軟是因?yàn)樗桓牧恕?重構(gòu),。 實(shí)驗(yàn)過已調(diào)整,。 已更正。 遞增,。

但是更改此代碼并非易事,，因?yàn)樵诖蠖鄶?shù)情況下，系統(tǒng)很復(fù)雜,。 變更的影響并不總是很明顯,。 我們害怕破壞某些東西而感到震驚。 這就是我們編寫自動化測試的原因,。 能夠無所畏懼地更改軟件,。 為了能夠重寫，調(diào)整,，試驗(yàn),，修復(fù)。

> Automated tests to measure the impact of change

不僅要知道軟件是否可以運(yùn)行,。 如果我們永遠(yuǎn)都不會改變該系統(tǒng),，那么經(jīng)過良好的手動測試將非常擅長于確保一個版本能夠正常工作。 也許比自動測試更好,，因?yàn)槭謩訙y試是強(qiáng)制性的端到端,，并且還可以捕獲UX和業(yè)務(wù)領(lǐng)域中無法預(yù)料的問題。

事實(shí)證明,，編寫自動化測試不足以使我們的軟件易于更改,。 如果代碼與實(shí)現(xiàn)細(xì)節(jié)（如UI，數(shù)據(jù)庫以及與其他系統(tǒng)的通信）過于耦合,，則代碼中的任何更改都將受到這些外部因素強(qiáng)加給我們代碼的固有建模的約束,。

對業(yè)務(wù)規(guī)則建模方式的任何更改都將在多個自動化測試和實(shí)施詳細(xì)信息中進(jìn)行更改。 要改善業(yè)務(wù)規(guī)則中變量的名稱,，就是要使其在數(shù)據(jù)庫,，屏幕或其他位置也進(jìn)行更改。 較大的變化,，結(jié)構(gòu)性變化會放松我們的脊柱,。

這就是創(chuàng)建架構(gòu)的原因。 在對系統(tǒng)建模時(shí),，架構(gòu)并不是要遵循的秘訣,。 這不是術(shù)語。 這不是將業(yè)務(wù)規(guī)則組織到類或方法中的方法,。 架構(gòu)不是DDD [1],。

架構(gòu)是將我們的代碼與外部因素隔離開來的方法，因此我們可以自由地以我們目前認(rèn)為最好的方式對問題的解決方案進(jìn)行建模和重新建模,。 然后重新進(jìn)行建模,。 然后再次。

當(dāng)今最著名的架構(gòu)之一是清潔建筑：

在本文中,，鮑勃叔叔似乎確實(shí)提供了秘訣,，術(shù)語以及將業(yè)務(wù)規(guī)則組織到類和方法中的方法。 但是,，如果仔細(xì)閱讀,，就會發(fā)現(xiàn)所有架構(gòu)的目標(biāo)都是實(shí)現(xiàn)所謂的獨(dú)立性，即所謂的自由,。

自由學(xué)習(xí)和改造系統(tǒng)而不會破壞一切,。 自由清理代碼,。

這就是為什么有用例（交互器）的原因。 它們代表用戶可以在系統(tǒng)中執(zhí)行的操作,。 它們是UI和應(yīng)用程序之間的通信橋梁,。 這就是為什么有Presenters的原因，當(dāng)涉及到一些額外的處理來呈現(xiàn)信息時(shí),，Presenter會從應(yīng)用程序返回到UI,。 它們是外殼的一部分，它們可以不同地命名,，也可以具有其他形式,，只要它們能夠發(fā)揮其隔離作用即可。

從那里開始,，不應(yīng)強(qiáng)加嚴(yán)格的規(guī)則,。 這才是重點(diǎn)。 不受規(guī)定的約束,。 我們已經(jīng)編寫了所有測試,，所有用例和演示者都存在，因此我們擁有更大的自由度來定義實(shí)體的狀態(tài)以及它們的行為方式,。

因此,，我們自己可以定義它們是否應(yīng)該是函數(shù)，類,，應(yīng)該具有多少種方法,。 如果它們將在網(wǎng)關(guān)（存儲庫）中實(shí)例化，則它們將在構(gòu)造函數(shù)或方法中接收數(shù)據(jù),。 以及任何其他建模方式,。

每個域都有其特殊性。 規(guī)則不適合,，原則適合,。 每個原理都將以給定的方式應(yīng)用于每個領(lǐng)域。 一切都取決于,。 但是要在這一點(diǎn)上前進(jìn),，我們需要習(xí)慣于重新思考。 也許回去做幾片kata或dojos,。

忘記規(guī)則,，忘記模式……解決問題的最簡單方法是什么？

忘記屏幕,，忘記數(shù)據(jù)庫…解決教授提出的大學(xué)挑戰(zhàn)的最簡單算法是什么,？

忘記用例，忘記體系結(jié)構(gòu)…編寫測試,，查看失敗,，編寫可能通過的最少代碼,，然后進(jìn)行重構(gòu)。

忘了上課,，忘了界面…更具可讀性的是什么,？ 對于剛開始在公司工作的新手來說，最容易理解的是什么,？

忘記模式,，忘記繼承…我放置此代碼的軟件包是否一致,？ 使用此規(guī)則的任何人都容易找到它嗎？

當(dāng)然,，我們將使用UI,，數(shù)據(jù)庫,，用例和模式，類,，接口和繼承,。 但是這些東西都是用來幫助我們?yōu)榻鉀Q問題的最簡單代碼建模的工具。

域的每個部分都有不同的問題,。 即使它們看起來都像相同的CRUD,。 系統(tǒng)的一部分將需要一個在構(gòu)造函數(shù)中具有數(shù)據(jù)的實(shí)體，另一部分將需要一個在網(wǎng)關(guān)內(nèi)部生成的實(shí)體,。 另一部分將需要其中包含許多規(guī)則的網(wǎng)關(guān),。 另一個將有一個僅由其他用例使用的用例，另一個將使它們?nèi)績?nèi)聯(lián),。

但是問題更重要：此代碼是目前最簡單的代碼嗎,？ 就是這樣，因?yàn)檫^一會我們會學(xué)到更多,，并將此代碼更改為更好的代碼,。

[1]《域驅(qū)動設(shè)計(jì)》一書探討了一些概念，這些概念有助于將應(yīng)用程序與外部因素隔離開來,，但目標(biāo)是以與業(yè)務(wù)領(lǐng)域一致的方式對業(yè)務(wù)規(guī)則進(jìn)行建模-這確實(shí)非常重要,，而另一個主題是 文章-并沒有過多地關(guān)注獨(dú)立性和自由性。

(本文翻譯自Caio Andrade的文章《What Exactly Is Software Architecture?》,，參考：https:///swlh/what-exactly-is-software-architecture-c1c67d1213f3)