戰略設計包含三項：適應度函數，增量，架構耦合
適應度函數:
在戰略實施的時候我們需要確定好測試策略，技術債管理，交互 。
測試策略在結構上可以包括：
（1）測試級別：常見的測試級別有單元測試，集成測試和系統測試。
從是否關心軟件內部結構和具體實現的角度劃分：白盒測 試，黑盒測試，灰盒測試
（2）角色與職責：需要在測試策略裏面明確定義各個角色，以及該角色的職責。
（3）環境需求：這一點非常重要，它將描述測試時需要的系統環境，包括軟硬件以及網絡環境等等。
在澄清環境需求的時候，測試組織可以識別出資源方面的風險。
（4）風險分析：影響測試過程的風險都應該儘早被識別出來，而且必須有相應的解決辦法以便消除或者減輕這些風險。
（5）測試進度：測試進度將會評估完成測試所需要的時間。
因爲測試過程中充滿了各種不確定性，所以一般計劃者需要考慮增加一定的buffer
（6）迴歸測試方法：迴歸測試用來保證之前fix bug的代碼不會影響軟件的其他部分，
這樣需要我們選擇已經執行過的測試用例重新運行。
（7）測試範圍：這個沒啥好說的，就是你要測試的內容，可能是某些模塊，可能是某些指標，比如功能，性能，易用性…
（8）測試優先級：測試範圍內的東西不會都是一樣重要的，加上測試資源各種有限，所以爲測試排定優先級是十分的必要
技術債管理：
技術債用於描述理想中的解決方案和當前解決方案中間的差距所隱含的潛在成本(當然也需要注意其中的“利息”問題。)
技術債治裏需要注意幾個要點:
核心領域優於其他子域
識別領域、子域是DDD戰略設計的重要步驟，在識別子域之後我們還需要進一步分析哪些是核心域（Core Domain），
哪些是支撐子域（Supporting SubDomain）和通用子域（Generic Subdomain）。
核心域在業務上至關重要，它提供了區別於行業競爭對手的差異化優勢，承載了業務背後最核心的基礎理念。
DDD概念的提出者 Eric Evans 是這樣描述核心域的：
The Core Domain should deliver about 20% of the total value of the entire system,
be about 5% of the code base, and take about 80% of the effort.
可演進性優於可維護性
技術債導致的可演進性問題大多和架構相關，比如服務和服務之間的循環依賴、模塊和模塊之間的過度耦合、
缺少模塊化和服務邊界的“大泥球”組件等，
在添加新的功能時，這些架構的壞味道會給產品功能的迭代造成不少麻煩。
比如服務之間如果存在循環依賴的問題，當你對系統進行少量更改時，它可能會對其他模塊產生連鎖反應，
這些模塊可能會產生意想不到的錯誤或者異常。
此外，如果兩個模塊過度耦合、相互依賴，則單個模塊的重用也變得極其困難。
明確清晰的責任定義優於鬆散無序的任務分配
增量
顧名思義就是技術債和交互的BUFFER
架構耦合
(1)解耦模式: 我們通過依賴倒置，控制反轉，依賴注入，面向接口等技術上的方式來降低耦合度
（2)安全策略:防範XSS攻擊,注入攻擊，CSRF攻擊，Session劫持，Error Code，輪詢，DDoS攻擊等，
現階段除了一些功能安全通過編碼解決外其他主要依靠防火牆和雲服務商來防範。
（3)技術債管理：接上文
（4)架構模式：模塊化，插件化，分層架構，依賴管理，微服務化
轉載請標明出處