Earlier in the week, I had a Neal treat at the City by the Bay, the beautiful San Francisco. Neal Ford, a long-time Thoughtworks leader was scheduled to do a session on Evolutionary Architecture. I have always been fascinated by what Neal had to say. Be it Functional programming, Technology Radar, or Architecture skills amongst the many topics he has spoken on, Neal brings a unique and interesting perspective. Evolutionary Architecture has been on my radar for a while to explore. It touches upon a compelling topic of how do you enforce your architecture so there is sanity in the code. The session at Thoughtworks gave me an opportunity to spend some time on the topic.
So, what is Evolutionary Architecture? As with any subject, we’d first need a definition to begin exploring. Neal defines it as follows.
An evolutionary architecture supports incremental, guided change as a first principle across multiple dimensions.
The three key aspects here are ‘incremental’, ‘guided change’, and ‘multiple dimensions’. If you have been into building non-trivial applications, you would know that features are released in increments. Each of these features would have to adhere to certain architectural traits. Typically, in organizations, there are architectural guidelines for teams to follow and build applications in accordance with the guidelines. Although the teams are sincere in their intent to align with the architecture, there are times when things go sideways. How would you enforce the rules? On top of that, there are several dimensions across which the architecture needs to be adhered to. There are a whole host of ‘ilities’ that you need to keep in mind. Wikipedia list a bunch of them here .
Let us dissect the concepts into pieces that we can use to define the architecture. Per Neal, these building blocks are Fitness Functions. These functions help us identify how we close or far are the solutions to the intended design. Here is the definition from the book.
a particular type of objective function that is used to summarize…how close a given design solution is to achieving the set aims.
Fitness functions can be viewed across various dimensions – atomic, holistic, batch, continuous. An atomic function would surround say a transaction. With holistic, you would want to cover a swathe of the application. Batch and continuous are self explanatory.
To aid writing fitness function, we have ArchUnit library. You can check out the library here . With archunit, you can codify the rules that capture your architecture. These tests can then be run within the pipeline. Any violation is stopped in its tracks. For instance, you can set a rule that the developer cannot call third party libraries directly. Or it could be that *Dao classes cannot be in a certain package. An example from archunit’s github codebase is presented below.
@Test
public void DAOs_must_reside_in_a_dao_package() {
classes().that().haveNameMatching(“.*Dao”).should().resideInAPackage(“..dao..”).as(“DAOs should reside in a package ‘..dao..'”).check(classes);
}
So, how do you actually bring the recommendations to fruition? Fitness Function Katas are here to our rescue. As Neal mentioned ‘Architecture Katas’, I felt nostalgic about Pragmatic Dave’s Code Katas that I had practiced back in the day. Architecture Katas have been a brain child of Ted Neward. For evolutionary architectures, the fitness function katas are listed on the companion book site. There are quite a few katas that you can try out. Guidelines on how to run the katas are also explained.
As I wrap up my narrative, here is what I suggest you do. First, check out the website http://evolutionaryarchitecture.com/ to start the journey. Second, get the book from here . Finally and most importantly, read and implement the Fitness Function Katas listed on the site and in the book.
Feel to leave comments below. I’d love know what you have to say.