Blog article
See all stories »

The Butterfly Effect

Butterfly Effect

We are currently doing some domain driven design to understand our primary business domains and identify the appropriate core APIs required. This is an exciting yet daunting time - some domains look far too simple while others seem overly complex and almost impossible to model. One such domain is the payments domain.

A few weeks ago, during one of the payment domain workshops, one of my colleagues compared payments to a butterfly and challenged me with the question: "How do you model a butterfly?" My knee-jerk reaction was to rise to the challenge and prove it possible, but I soon ran into the problem. Butterflies are the end state of metamorphosis.

The butterfly has four stages to its lifecycle; egg, caterpillar, pupa, butterfly. Each stage is different and has a different goal. The challenging part is, while the creature is the same, its life stages are completely different. The egg is simply a sphere with something growing inside. The caterpillar is a long cylindrical creature with a lot of legs. The pupa is a mass of thread woven into a cocoon shape. The butterfly has wings and six legs. How can the same creature be modeled if it is a completely different object during the stages of its life.

This stuck with me for a while as I consciously left it to percolate in the back of my mind. Yesterday, while on my way home on the metro, I had the "Aha" moment!

The answer is you can model a butterfly - by the individual stages of the creature at any moment. The question leads you to assume you need to model all stages of the creature as one model since it is one creature. This you cannot model. The relationship between metamorphosis and the butterfly is the same as payment to transaction. Both are a process, not an entity

So, simply put, model the stages of the payment process as separate entities and serve these as core domain APIs. Next, create process APIs that manage and orchestrate these core domain APIs to fulfil the payment process. 

It's just as important to phrase the question as it is to understand it. 


Craig Hughes

Photo by Ahmed Aqtai from Pexels


Comments: (4)

João Bohner
João Bohner - Independent Consultant - Carapicuiba 08 September, 2018, 00:101 like 1 like

wise comparison between the processes on a life of a butterfly and the activities on a financial process.
This comparison fits like a glove in the "Bank of the Future" platform Architecture, which handles all financial processes - not only payments.
Both are simple, direct and definitive.
The difference is that the butterfly dies and disappears and the history of financial processes is kept 'ad aeternum'.
I'm doing a butterfly evolution drawing, comparing it with the BotF Architecture.

Craig Hughes
Craig Hughes - Danske Bank - Copenhagen 09 September, 2018, 11:15Be the first to give this comment the thumbs up 0 likes


Thank you for your comments and insight. I'd be keen to see your BotF diagram once you have it completed.

João Bohner
João Bohner - Independent Consultant - Carapicuiba 11 September, 2018, 03:10Be the first to give this comment the thumbs up 0 likes


The picture is completed.

As I can't upload pictures in the comments, pls send an email to do so.

Craig Hughes
Craig Hughes - Danske Bank - Copenhagen 11 September, 2018, 07:34Be the first to give this comment the thumbs up 0 likes


Thank you! I have sent you an email.


Craig Hughes

Craig Hughes

Chief Enterprise Architect API

Danske Bank

Member since

06 Sep 2018



Blog posts




More from Craig

Blog post

Chain of Trust

Blog post

API Misconceptions

Blog post

API Fragments - simple flexibility

Blog post

API: Arrays or named elements?

This post is from a series of posts in the group:

Banking Architecture

A community for discussing the latest happenings in banking IT. Credit Crunch impacting Risk Systems overall, revamp of mortgage backed securities, payment transformations, include business, technology, data and systems architecture capturing IT trends, 'what to dos?' concerning design of systems.

See all