Paula Paul和Rosemary Wang撰寫的一篇博文中介紹了適應度函數（fitness function）的基本概念、入門方法，並給出瞭如何驗證各種架構質量的一些實例。文中提出，適應度函數驅動開發的方法可用於編寫測定系統符合架構目標的測試，這類似於使用測試驅動開發（TDO）的方法驗證功能是否符合所需的業務輸出。
Paul和Wang均供職於Thoughtworks。文中強調指出，架構標準完全獨立於功能需求，它是隨着目標和限制條件的更改而持續演進的。作者們引用了《構建演進架構》（“Building Evolutionary Architecture”）一書中的說法：
從多個維度上看，演進架構的首要原則是支持受控的增量更改。
Paul和Wang認爲，對於支持這樣的架構演進，適應度函數有助於自動確定系統在多大程度上符合特定的架構目標和限制條件。舉個例子，打日誌的方法通常是事後諸葛亮，並缺少一些重要的信息。如果引入適應度函數功能，可確保日誌具有良好的結構化，幷包含足夠的有用信息。
對於使用適應度函數的時機，作者們給出的建議是首先收集所有利益相關者的意見，瞭解在他們看來最爲重要的架構功能。之後對這些功能區分爲通用主題組，比如彈性、安全性、可操作性和穩定性等。有時，在分組時會暴露出一些相互衝突的目標。例如，穩定性和敏捷性這二者的目標通常是截然相反的。穩定性是通過建立對更改的控制而實現的，而敏捷性是通過減少實現更改的障礙而實現的。爲了解決目標衝突的問題，必須對各項功能的動機加以評估，對組織最爲重要的功能應優先處理。
在描述所有適應度函數的意圖時，應使用對團隊和利益相關者有意義的客觀度量。度量有助於團隊測定技術債務，同時也避免架構偏移。所有的適應度函數都應在測試框架中制定，並添加到適當的交付流水線中。這樣，所有新的軟件都需要通過適應度函數的測試。Paul和Wang將此視爲持續集成的一種自然延伸。
文中給出了一個針對代碼質量的適應度函數示例。該例測定了可修改性、可管理性和適應性，以防止將質量過低的代碼部署到生產環境中。
describe "Code Quality" do
it "has test coverage above 90%" do
expect(quality.get_test_coverage()).to > .9
end
it "has maintainability rating of .1 or higher (B)" do
expect(quality.get_maintainability_rating()).to < .1
end
end
文中還給出了一個針對性能的示例。Paul和Wang指出，由單獨團隊完成的常規做法會延遲交付時間，並且結果並非總是提供給開發人員的。而將自動化性能測試實現爲適應度函數並添加到構建流水線中的做法，可以儘早地運行測試，並且也可以立即看到結果。
除了上述兩個示例，作者們還在文中針對彈性、可觀測性、符合度、安全和可操作性給出了示例。
Paul和Wang最後強調，架構（例如業務功能）可通過適應度函數的方式在代碼中予以表達。他們在文中提出，使用適應度函數具有三方面的優勢：
- 適應度函數客觀地衡量了技術債務，並提高了代碼的質量。一旦由於新的安全性或操作標準等原因而發生更改時，適應度函數還可提供實時反饋。
- 適應度函數可提供編碼選擇的信息，包括與下游進程相關的接口、事件和API的選擇。在應用“絞殺者模式”（strangler pattern）時，適應度函數可用於驗證業務邏輯解耦過程是否滿足要求。
- 適應度函數支持以代碼形式表達架構標準，從而有助於開發人員交付更加符合架構的功能。使用同一方式，用戶可以請求更改功能，架構師可以請求更改某些架構問題，這些都可以在構建過程中加以驗證。
在一篇博文中，Ben Morris強調了使用適應度函數而非實際度量的重要性。在Morris看來，適應度函數爲更具迭代性的架構提供了基礎，並可引導持續演進的設計朝着理想的結果發展。
Vijini Mallawaarachchi介紹了適應度函數的一般需求(https://towardsdatascience.com/how-to-define-a-fitness-function-in-a-genetic-algorithm-be572b9ea3b4)，以及如何針對特定問題給出適應度函數。
Tim Sommer撰文指出，適應度函數可用於爲各種架構特性添加約束條件，進而引導架構的演進方向。
查看英文原文： Fitness Functions to Ensure Architectural Goals Are Met