Software Architecture

Fitness Functions for Governance

Two ways to automate the governance for component dependencies are to make sure no component has “too many” dependencies, and to restrict certain components from being coupled to other components. The fitness functions described next are some ways of governing these type of dependencies.
Fitness function: No component shall have more than of total dependencies
This automated holistic fitness function can be triggered on deployment through a CI/CD pipeline to make sure that the coupling level of any given component doesn’t exceed a certain threshold. It is up to the architect to determine that this maximum threshold should be based on the overall level of coupling within the application and the number of components. An alert generated from this fitness function allows the architect to discuss any sort of increase in coupling with the development team, possibly promoting action to break apart components to reduce coupling. This fitness function could also be modified to generate an alert for a threshold limit of incoming only, outgoing only, or both (as separate fitness functions). Example 5-8 shows the pseudocode for sending an alert if the total coupling (incoming and outgoing) exceeds a combined level of 15, which for most applications would be considered relatively high.
Example 5-8. Pseudocode for limiting the total number of dependencies of any given component
# Walk the directory structure, gathering components and the source code files

# contained within those components

LIST

component_list

=

identify_components

(
root_directory
)

MAP

component_source_file_map

FOREACH

component

IN

component_list

{

LIST

component_source_file_list

=

get_source_files

(
component
)

ADD

component
,

component_source_file_list

TO

component_source_file_map

}


# Determine how many references exist for each source file and send an alert if

# the total dependency count is greater than 15

FOREACH

component

,
component_source_file_list

IN

component_source_file_map

{

FOREACH

source_file

IN

component_source_file_list

{

incoming

count

=

used_by_other_components

(
source_file
,

component_source_file_map

)

{

outgoing_count

=

uses_other_components

(
source_file
)

{

total_count

=

incoming

count

+

outgoing

count

}

IF

total_count

>

15

{

send_alert

(
component
,

total_count

)

}

}

Fitness function: should not have a dependency on

This automated holistic fitness function can be triggered on deployment through a CI/CD pipeline to restrict certain components from having a dependency on other ones. In most cases, there will be one fitness function for each dependency restriction so that, if there were 10 different component restrictions, there would be 10 different fitness functions, one for each component in question. Example 5-9 shows an example using ArchUnit for ensuring that the Ticket Maintenance component (ss.ticket.maintenance) does not have a dependency on the Expert Profile component (ss.expert.profile).
Example 5-9. ArchUnit code for governing dependency restrictions between components