上一節說了戰略設計的大致思路，這節開始軟件架構的核心戰術設計，
戰術設計方式非常多種方式，業務需求不同複雜點也不一樣戰術設計的方向也不一樣，
我們進行戰術設計的主要目的也是爲了解決軟件複雜度帶來的問題，
因此我們很多時候是針對系統複雜點來進行設計，所以很多時候我們不需要一味追求系統的、高併發，或者照搬巨頭公司的架構方案，更不必追求流行，要看自己的系統到底有什麼問題。
有時候是爲了實現系統的高性能、高併發等需求，反而給系統帶來了複雜度。
複雜度的來源：
1，可擴展性：
可擴展性指系統爲了應對將來需求變化而提供的一種擴展能力，當有新的需求出現時，系統不需要或者僅需要少量修改就可以支持，無須整個系統重構或者重建。
滿足可擴展性需要兩個基本條件，正確的預測變化，完美的封裝變化
並且不能每個設計點都考慮可擴展性（架構設計會異常龐大，最終無法落地），不能完全不考慮可擴展性，所有的預測都存在出錯的可能性
應對變化：一種應對變化的常見方案時將“變化”封裝在“變化層”，不變的部分封裝在獨立的“穩定層”。
另外一種應對變化的常見方案是提煉出一個“抽象層”和一個”實現層”。抽象層是穩定的，一般不做修改，
實現層根據業務來定製。這種方案的典型實踐是設計模式和規則引擎
2，低成本：當系統需要很多服務器，多次重複部署，頻繁的維護時成本就會是一個重要環節，這時效率越高成本也就會越低。
戰術設計的架構方向:分層架構(或者六邊形架構)，依賴管理，模塊化，插件化，微服務。
其他方向:架構守護，架構決策記錄,代碼掃描，適應度函數流水線，零信任網絡安全策略，測試金字塔。
分層：DDD經典分層--UI層，APPLICATION應用層，CORE領域層，數據庫實體層
UI層:負責向用戶展現信息以及解釋命令
APPLICATION應用層：定義軟件要完成的所有任務。對外爲展現層提供各種應用功能(包括查詢或命令)，對內調用領域層(領域對象或領域服務)完成各種業務邏輯。
領域層:表達業務概念，業務狀態信息以及業務規則
基礎設施層：爲其他層提供技術能力，提供層間通信。
分層架構遵循關注點分離的原則，將屬於業務邏輯的關注點放到領域層中，將支持業務邏輯的技術實現放在基礎設施層中，
同時應用層扮演着雙重角色，一方面作爲業務邏輯的外觀，暴露了能夠體現業務用例的應用服務接口；
另一方面他又是業務邏輯與技術實現的粘合劑，實現二者之間的協作。
一般我們會在領域層中建立資源庫REPOSITORY的抽象，他的實現則放在基礎設施層，然後採用依賴注入在運行時爲業務邏輯注入具體的資源庫實現。
那麼，對於處於內核之外的REPOSITORIES模塊而言，即使選擇從sqlserver遷移到mysql領域代碼都不會收到牽連。