I’ve been doing a whole lot of thinking about the nature of happiness over the past few years. It’s a matter of record that 2024 was a suboptimal year for me but my thinking on the topic of happiness started well before then and I’ve only really managed to get my thoughts together on it recently. I’m sure they’ll continue to evolve over time.

This post was challenging to write, and still doesn’t feel particularly coherent. Please forgive me if it doesn’t align with your thinking. You’re entitled to your thoughts, just as I am to mine. If this post helps someone then that will be enough. If it doesn’t help you then please just move along with grace. Or tear me down if you think that will do good in the world. Your call. What qualifications in this area do I have? None. Again, please just move on if you wish. I won’t mind.

Partly this post was so challenging to write because I was trying (and failing) to disentangle “happiness” from “healing”. Let’s be honest: as an adult, you’ve probably both hurt others and been hurt yourself. We all have scars. There’s always some healing to be done, and, while there can always also be happiness, disentangling the two is much more challenging than we’d like it to be. In hindsight I don’t think we should. Healing can enable happiness; likewise, happiness can aid healing.

So… Let’s start with an easy question: “What is happiness?”

What is happiness?

My personal definition of happiness is perhaps a little different to yours, and I’m okay with that: Happiness is an emotion so positive and powerful that you feel impelled to gift it to others.

When we’re a child, this seems to be an unquestioned assumption and an unconscious action - possibly because we’re almost always around others. We openly laugh in delight at a funny-shaped cloud, a pretty bird or when someone pulls a funny face at us or plays peek-a-boo. We’re already unconsciously sharing our joy in those experiences with those around us, either verbally/vocally or by something visible like when we choose a beautiful butterfly for our face painting or wear our favourite cute socks. Yes, it’s for ourselves, but it’s also for other people. We just don’t think of that too consciously because… well… we’re a child and we’re surrounded by other people, so of course we’re sharing.

As adults, we become much more self-conscious about displaying happiness. Apparently it’s weak or some such rubbish. I saw that again at Schoolies again this year - people trying to be “grown up” and reluctant to display happiness and joy for fear of still being taken for a child. One of the lessons I re-learned far later than I should have was that when you choose to let others see your happiness and delight, your company becomes a gift to other people. In other words, your happiness shines brightly onto others and brings them happiness and joy in turn. I will be forever grateful for the friends - you know who you are - who taught me that lesson by your example. Your childlike appreciation of the world around you is wonderful and inspiring. Please don’t let yourselves lose that. Please don’t stop taking that childlike delight in the world.

So yes, our happiness shines brightly onto others. It doesn’t stop there, though. When our happiness shines brightly onto others, it reflects from them back onto us. We feel our own happiness mirrored by the people around us, and that in turn brings more happiness. That, in turn, is reflected back yet again, and a virtuous cycle arises.

In other words, happiness shared is happiness multiplied.

The whole is greater than the sum of its parts

The word we’re looking for here is “gestalt”.

That’s what I think we miss so much when we’re alone: even when we are whole, we are still only one, but with someone special who is also whole we are so much more blessed. We appreciate what we have, but we also understand what could be.

So… if happiness shared is happiness multiplied, can this be a two-edged sword? Multiplicative effects aren’t always to our advantage. The whole can be greater than the sum product of its parts, but those parts ultimately both need to be whole in and of themselves for that to hold true.

Forgive me, but I’m going to speak in C# for a minute. Laugh if you will. I don’t care - see previous comments about childlike fun. This is fun for me 🙂

public decimal CalculateTotalHappiness(decimal happinessA, decimal happinessB)
{
    // No, I'm not going to check inputs.
    //
    // This method will accept two
    // negatives and return a positive.
    //
    // That's clearly ridiculous.

    if (happinessA < 1 && happinessB < 1)
    {
        // Total happiness is reduced. A lot.
        //
        // Each person makes the other less
        // happy.
        //
        // E.g. 0.5 * 0.5 == 0.25 happiness
        // for both parties.
        //
        // We're making each other miserable.
    }
    else if ((happinessA >= 1 && happinessB < 1) || (happinessA < 1 && happinessB >= 1))
    {
        // One person is leeching happiness
        // from the other.

        // This is sustainable, and often
        // *important*, for short spans of
        // time, but if if it becomes chronic
        // then we have a problem.
    }
    else if (happinessA == 1 && happinessB == 1)
    {
        // Each person is sufficiently happy
        // but total happiness is unchanged.
        //
        // We're okay.
        //
        // This is what we might call a
        // "situationship".
    }
    else if (happinessA > 1 && happinessB > 1)
    {
        // Total happiness increases
        // exponentially.
        //
        // E.g. 2 * 2 happiness == 4 happiness.
        //
        // TODO This is where we want to be.
    }
}

On being happy alone

In a previous post on Why does beautiful often mean melancholy? I quoted a friend as saying over dinner that they weren’t interested in travelling unless it was with someone special. They were quite firm on that but didn’t quite understand why, and although I shared that sentiment I didn’t understand, either. Now, I think I do. It’s not a matter of being unhappy alone. It’s a matter of the return on investment on doing something alone versus doing that same something with someone special.

I like going to the beach. Going to the beach is a happy experience for me, especially if that beach itself is a special location for me. I really like going to the beach with friends. I love going to the beach with someone special. With someone else who is important to me (whether family, friend or partner) I see that joy and delight reflected back at me, and that’s both a gift to someone else and their gift in return to me. We both gain more from sharing the experience than if we were to each have that experience separately.

I’ve mentioned before that a dear friend once introduced me to the philosophy of Alfred Adler. His thoughts are worth considering, even if not entirely adopting¹. One of his positions is that we have to be whole and self-reliant, and that we have to have the courage to chart our own course in life and to accept that others may dislike us as a result of our decisions. We must have the courage to be true to ourselves, accept the consequences and be content. Another of his positions, however, is that humans all share the basic goal of belonging and contributing to a community, which means that “being true to ourselves” also has to take into account our contribution to others.

These positions at first glance appear to be in conflict with each other but they don’t have to be.² If we’re not content within ourselves then we’ll make a net-negative contribution to our community, which is unhealthy. If we bring a whole person to a friendship, relationship or community then our contribution will be a vastly more positive one.

Healing and wholeness

This is where it gets complicated, because now we have to talk about healing.

Every person has scars. Some still have wounds. Some are from long ago; some are recent. All experiences have left their mark. This is what we call “being human”.

If each party needs to bring more than one happiness, does that always need to be the case? I think not. It should be the ideal case, and it’s almost certainly going to be required to be sustainable, but I think it’s very human for people to lean on each other to heal, provided that that’s done in a healthy way and results in actual healing rather than co-dependence.

Many people will make statements along the lines of, “You have to be whole in yourself before seeking someone else,” and while I partially agree with it I do view it as only a partial truth. Yes, it’s important to be a whole person. If you’re broken then some reassambly is required. That’s the simple part. Does that healing need to happen alone? Much more complicated.

Do we need to heal alone? I don’t think so. Do we need to start healing alone? Also, I don’t think so. Relying on family, friends and/or professional help to begin and facilitate healing is entirely human. There is a trap, however: relying on another person/people to heal us, rather than healing ourselves with the aid of other people. Kant has some firm opinions on using people as a means to an end. In the context of a relationship, a skydiver friend referred me to the term “grip-switching”. Not recommended.

In the case of violence etc. perhaps there’s no place for that person/people in our lives any longer. No blanket statements from me here but if that’s your situation I’m certainly not going to question it.

Other than the above, if two people hurt each other but aren’t willing to completely cut ties then my position is, complicatedly, “Not all healing should be done alone.” Moreover, some can’t be done alone. Some needs to be done alone (or at least apart) first, in order to re-establish our own equilibrium and our own boundaries, and to set ourselves up for success in the next phase. The next phase, though, needs to be done together in order to mutually repair the wounds we caused. There’s a difference between “healing” and “scarring”. Some wounds will just scar over. Some may genuinely repair. Who knows?

Some healing requires apologising to people we hurt, and/or to God if we’re of faith. I’m reliably assured that divine forgiveness is infinite, but I don’t discount the value of human forgiveness, either. Sometimes we need both.

Do we need to be able to stand alone? Ultimately, in my view, yes. What we do with that ability is up to us. No (wo)man is an island.

So how/where do I find happiness?

Oh, no. This one’s over to you. Finding your happiness is your task.

One lesson a dear friend demonstrated to me over time, perhaps unconsciously, was that the more quickly one could switch serious-face on, the less we had to wear serious-face by default. They could flip a mental switch and show a very (!!) serious face on next-to-no notice. What that meant was that they could more easily relax into the moment, and only be serious when it was necessary. I’ve since been cultivating that skill, and have found that it really does work - being able to context-switch to “serious adult” has meant that I can spend much more time defaulting to taking a childlike delight in the sights, sounds and experiences around me. I can squirrel at a pretty flower, a funny-looking chicken or even an actual squirrel³. Perhaps that lesson will help you. Perhaps it was already blindingly obvious to you, and I’m the slow one here. I’m okay with that 🙂

For me?

I support my family, my friends and other loved ones. I try to take the time to appreciate the beauty in the world around me, and be grateful for its existence. I seek out new skills but try to actually learn the ones I choose rather than just dabble in many things. Dabbling is fine to get a taste of something, but - for me - true enjoyment of an activity usually comes with competence. There’s already quite a long list of sports, activities and other pursuits that I enjoy; I don’t need to re-list those here. I give back to my community, but with little fanfare. I share the lessons my own mistakes have taught me. I play.

Your mileage may vary. I wish you well.

So 2024 has been a suboptimal year in my world.

It’s worth bearing in mind that good and bad are not a single dimension. This year has had an awful lot of bad (an awful, awful lot) but also a wonderful amount of good in it. That said, I think it’s safe to say that I wouldn’t survive another year like this. I don’t think I’d choose to survive another year like this. Almost no matter the good, sometimes the horrible is quite simply horrible.

I am grateful to the friends and family who surrounded me in the darkest times. I have drunk a lot of tea with a lot of people. There have been tears and despair. There has been support which humbled me and which I still don’t feel I deserved. Whether you sat and drank tea with me, gave me a place to stay, baked me brownies, hugged me, took me to dinner and fed me steak and shiraz, made me dinner and fed me steak and Bordeaux, reality-checked me, pestered me to come out on the bike, dragged me out to a random friend’s birthday dinner, came to parkrun with me when you really didn’t feel like running, or just bluntly told me harsh truths about life, thank you. For all of those things and more, to all of those people: you know who you are, and I am grateful to you all beyond measure:

Calling time on a marriage is never something done lightly, and it was an extremely difficult and painful decision. I still have a great deal of respect for Syndia, and I do ask that people respect what’s also a very difficult time for her.

Regretfully parting company with some close friends has also been extremely painful but sadly unavoidable. I wish it were not so, but if wishes were fishes… 🤷‍♂️ Perhaps that’s permanent; perhaps not. I hope not, but that’s out of my hands, and what will be will be.

Saying vale to Scoon was a sad, sad time. Life really doesn’t deal a fair hand to some people. At least we got to spend some time together towards the end doing silly, fun things. Hooning around the mountains in a turbo Subaru with Scoon and Fadge whilst alternating between laughter, dark humour and tears is a memory I’ll hold dear forever. I had promised to not kill us early in a flaming wreck but Fadge may have not quite believed me at the time.

Having several friends end up in hospital for issues of varying severity was impactful, both because I care about them but also as a reminder of my own mortality. Not that I needed that (see below) but the reminder nonetheless hits close to home.

I am reminded, however, that I am blessed in so many ways. I have wonderful family and friends around me. Upon hearing some of this year’s news, friends I hadn’t seen in years came out of the woodwork to offer support, and I’ll be forever grateful for that.

There’s a quote from Confucius, popularised by - of all people - Jimmy Carr: “A man has two lives. The first life begins at birth; the second when he realises he has but one.” Never has that quote been more apt for me than now.

My yearly theme for 2024 ended up becoming “Genesis” - the original meaning being “new beginnings”. Well, there wasn’t much left of the old, so new beginnings it had to be, and it was.

This year I hiked (strolled, if we’re being honest) Mount Coolum with Joey, hiked O’Reilly’s with Fadge, Mitch, Elise and Jess on a number of occasions, climbed Beerwah solo (perhaps not my brightest idea but it was worth it). I kayaked in the Brisbane River, jumped out of aircraft, ran countless parkruns, ran my first half-marathon and a bunch of other things.

I’ve picked up the violin again and am loving it. I’m rusty, of course, but much less so than I’d expected. Sometimes it sounds pretty ordinary but when I get it right I can make that instrument sing. I’m not messing around. I will be gigging in 2025 one way or another.

I’m singing again. I’m singing really well. Between voice and violin and a few other things, I’m genuinely amazed at how transformative an experience it is to have so much music back in my life. It’s wonderful. It’s beyond wonderful. Never again will I let that go.

I’m taking my cameras out more and more often. When I don’t have an SLR with me I still have my phone, and Ansel Adams has opinions about the best camera. Once upon a time I made the decision to sell my photography. It was a valid decision at the time and I stand by it, but I did sell something I loved. Never again. I will never again sell another image. I’ll do volunteer gigs on occasion, and shoot the odd portrait for a friend here or there, but it’s on my terms and I won’t accept payment. As a result, I’m again viewing the world through a different lens (ha!) and re-learning how to appreciate it in all its beauty. If you’re following me on all the different social channels I’m sure you’ll have seen that.

I’ve enrolled in a postgraduate course in counselling for next year. I don’t expect to practise; nor is it to help me professionally - although, of course, just being a better person will help across the board. No, I’m doing that just for myself. I need to better understand how my own mind works. Given the number of deep conversations I’ve had with other people (not just this year but especially this year), I also need to better understand how to help them, and where my own limits are before suggesting professional help. I also want to understand how I failed some people entirely despite my best efforts and what I could have done differently.

I’m back as a mentor again in the Tattersall’s mentoring program. Given my rubbish 2024 I didn’t think it’d be fair to be a mentor for anyone else when I was barely holding things together myself, but my self-reassembly project has gone well and is continuing to go well and I’m in a better place than ever to help others.

My fitness has improved out of sight, and I wasn’t doing badly before. I’m hovering between eight and ten percent body fat, lifting more than ever and feeling great. I won a pull-up contest with a schoolie whilst wearing a backpack full of water, medical supplies, pancake mix etc. and wearing heavy hiking boots. I’m running more, cycling a little less (for now…), hiking more and lifting and swimming regularly. All of this has helped to improve my mental state beyond measure and I’m so very pleased with how I look and feel. I have nobody to show it off to at present, but that will be what it will be and I am content.

Work-wise: we smashed it this year. I can’t say much more than that, other than that I’m so very proud of my department (and, yes, myself) for how things went. Again, no life partner to share that with but my people know, and I know, and that’s enough. For the work folk: “kuberneetus” will forever be a real word.

My MS hasn’t progressed detectably at all for years. I guess now is as good a time as any to de-cloak that: yes, I have Multiple Sclerosis. A very, very small number of friends and family knew and respected that confidence. Thank you. It was diagnosed in October 2011 and provided me with my own mortality reality-check. I did say earlier that I hadn’t needed any more, didn’t I? So, yes, I have MS and have been on treatment for it since 2011. The drug I was on (which was state-of-the-art at the time and very effective) has recently been swapped out for a newer one which isn’t a “cure” per se but is basically one dose every five years and then living a completely normal life. If it walks like a cure and quacks like a cure, I’ll take it.

Learning to live truly alone this year, and to be alone with my own thoughts, was transformative. It wasn’t easy - nor was I expecting it to be - but I’ve learned to be content and at peace with my existence. That was hard, especially without the crutch of a partner, housemate, pet or even a house plant. Choosing “alone” meant “truly alone” and I’m proud of having done that and come out the other side.

Speaking of living truly alone… I love living in my apartment. It’s small (two bedrooms; one of which is reserved for my daughter) but right on the river at St Lucia. I wake up every morning to sunrise over the rippling water, the sound of the rowing crews training, and bike bells from people on the river loop. It’s beautiful at night, too, with the city lights shimmering over the water. It’s peaceful and beautiful and I love it there.

I’ve also made quite a number of new friends this year, and many in a rather unexpected context: church. Go ahead. Laugh. Laugh loudly. I’ll cope 🙂 In hindsight, I’ve been on this particular journey for many years, but hindsight is 20/20, isn’t it? What journey? The one from “militant atheist” to “reluctant atheist” to “well, you can’t call yourself an atheist if you’re having conversations with God, can you?” to Christian. I had a conversation some time ago with some close friends in which I described myself as a reluctant atheist. I wished that I could believe in a god who cared about people but just couldn’t bring myself to. To cut a multi-decade-long story short, when I crossed the threshold of my local church I was neither turned into a pillar of salt nor struck by lightning, and things progressed from there.

I’ll be forever grateful to the people who introduced me to that church long ago, even though it took until now for me to fully appreciate it. I’m sorry for being so slow in that regard. I’ll also be forever grateful to the then-strangers who greeted me there, patiently fielded my nebulously-articulated questions, respected my confidences, shared their own, and ultimately became my friends.

One upshot of rejoining the faith I firmly left at fourteen years old after being tossed out of my RE class for daring to ask questions was that I was finally eligible to be a Red Frog. I’d been involved to some extent with the frogs for many years but not been eligible to be one. The requirements are stringent and although I already had a Blue Card and all sorts of criminal history checks (working in financial services requires one to be squeaky-clean) the one element I was missing was a pastoral reference, which this year was very graciously provided. I hope I did you proud, Caleb.

So… yes, this year I went to Schoolies on the Gold Coast as a Red Frog. I wasn’t expecting anything for myself - it’s not about us, after all, but about safeguarding a new generation. That said, at about 2am one morning after my team had already walked about a half-marathon that night in the unrelenting rain and bitterly-cold wind with no end in sight, I felt peace. Our boots were wet, we were soaked, we’d just gotten another drunken schoolie safely home and cleaned up the vomit, and were walking back to the Red Frogs walk-home tents to pick up some more. It was a miserable night, yet that helped me remind myself that it wasn’t about us, and that we were here for them, not ourselves. And then we decided we’d make it a happy night anyway, and splashed through the puddles singing The Duck Song and 500 Miles.

Choosing how to view those miserable circumstances is a good lesson in life, and the power our choice of how to respond has. A dear friend once directed me towards the philosophy of Alfred Adler. Whilst some of his thinking has been superseded by newer medical knowledge, much still holds true. His view of “life tasks” and the “separation of tasks” is very powerful and I’d encourage a look into his philosophy. Nobody could live this year for me - that was my task, as are many others, just as I couldn’t live other people’s tasks for them. While you’re reading Adler, perhaps read some Camus as well as the standard Kant and Nietzsche. The world really can be absurd and we were never promised fairness (although we can strive to create it), understanding or even an explanation. Also read some Job and perhaps Corinthians. You might be surprised at what you find. I was.

So… where to from here for me? What does the future hold? In all honesty, while I wish I knew, I am at peace with where I am, and content with what I have.

My yearly theme for 2025 is “Renaissance Man”.

There are many things for which I hope; some realistic and some of which would take a miracle. I do hope and pray for the miracles, but I also work towards what’s within my control. Either way, I am where I am and the future will be what it will be.

I would like, of course, to eventually create something special with someone special. While I’m whole, comfortable and content alone, the union of two people creates something much more than the sum of its parts. It took me an embarrassingly long time to truly understand that. Anything that does happen in that regard needs to begin with friendship, and that’s what I’m seeking at the moment: investing in existing friendships, perhaps resurrecting some old ones I regret losing, and also developing new ones. I’ve met some wonderful people this year and if “all” I end up with is new, good friends then that’s a very happy place to be.

Whilst meeting someone is outside of my control, there are many things which are within my control. The Serenity Prayer gives guidance on what to do about those. I’m going to explore more, both with friends and solo. I’m going to take my daughter to dinner, watch her play volleyball, turn up to her debates and concerts, and continue to be the best father I can be for her. I’m going to sing more, play more and enjoy music more. I will share my life’s expensive and painful lessons freely in the hope that others can learn from them without having to make the same mistakes. I will teach, guide and mentor. I will learn. I will drive my hoon-mobile modded Subaru the way it was intended - fast, loud and occasionally sideways, with the sunroof open and the obnoxious sound system turned up to eleven. I will ride my motorcycle, race my bicycles, take my photos, jump out of aircraft, paddle my kayaks, dance, sing and play. If there’s someone special with whom to share those experiences, so be it, but I’m also going to share them with my friends. I’m going to live my life, not just survive to the finish line.

I will be the best father I can be.

I will be the best friend I can be.

I will be the best person I can be.

I will be the best version of myself I can be.

What does the future hold for me? I am content with my path. I have my tasks and I am working to make good on them. What will be will be, and I am at peace.

What does the future hold for you? That is your task. I hope you discharge it well. If I may help, please say the word - but I won’t intrude on your tasks.

P.S. I’d originally intended to schedule this post for release just before midnight on New Year’s Eve, but it’s relevant now so out it goes. Perhaps I’ll re-work it and re-post it later; perhaps not. Read it while you can, if you wish.

Hi all.. So I’m trying to understand something about myself and am wondering how many others feel this way and how you approach it.

When I see something beautiful I appreciate it but the feeling of delight and wonder I get is often coloured by a melancholy undertone.

I don’t think I want this. I enjoy the delight, the joy and the wonder of seeing and experiencing beautiful things (have you noticed a bunch of sunrise/sunset/nature photos recently, dear reader?) but it feels odd that it also sometimes creates that feeling of sadness. The sadness isn’t there all the time but it seems to flare when the happiness does as well. This feels odd.

I’ve asked several close friends and family and I’m definitely not alone in this feeling, but nobody I’ve spoken to who feels similarly (and there are several) seems to understand why.

I learned some invaluable lessons from a few more friends over the years (you know who you are, and thank you) about taking joy and delight in the moment, and I’m doing that better now than I ever have. I stop during a parkrun to photograph a pretty tree or an interesting creature. I squirrel at a bird doing something silly or a single flower in a shrubbery. I stop during an adventure race for a smoothie because there’s a stall selling them, and during a rainy sportive at a cafe to drink coffee and watch a ridiculous scrawny chicken (don’t ask). I sing. I dance. I sports. I love doing all these things. I play.

One friend has said that he doesn’t travel solo much because he wants (needs?) to share the experience with someone special. Another has quoted the character Beverley Clark from Shall we Dance: “We need a witness to our lives.” I know I presently lack a partner to share it with and that’s a part of it but not the whole story - it’s not just a recent thing.

I want to see a beautiful sight and simply be happy to have had that experience. No side-helping of wistful anything. Adler says (over-simplified summary) that we can simply choose to be content with having had that experience. Have you achieved this? If so, how? Were you always that way? Is it a skill you learned?

Is this why so many people Instagram their lives? What’s your own experience?

P.S. Yes, I’ll also ask a psychologist or two and report back 🙂

P.P.S. I think I have my answer

There are many flavours of event-driven architecture. I tend to speak and write a lot about event choreography, as 1) it’s a pattern that allows for effective separation of concerns, and 2) it’s a more accessible introduction to event-driven architectures than things like event sourcing. (Although I do make noise about event sourcing, too.)

In particular, in-process event choreography is extremely useful as it allows different parts of the same codebase to take action without being directly coupled together, but still allows for all of the state changes to be committed within a single transaction. Similarly, for distributed systems, event choreography is a powerful pattern to deliver simple, scalable workflows across disparate parts of an organisation.

Choreography versus orchestration

It is, however, important to draw a distinction between choreography and orchestration. If the system that will perform the action makes the decision, it’s choreography. If the system that will perform the action gets told to do it by another system, it’s orchestration.

The key is which system decides that an action should be taken.

• Choreography is when a system takes independent action of its own volution as a result of the action of another system.
• Orchestration is when some kind of process manager instructs a system to take action, usually as a result of an action of another system.

So which should I use? How do I decide?

This brings us to the question of which we should use and when. A simple rule of thumb is if a business process has a name and some state, it’s an entity. When we speak in terms of rules, e.g. “When a customer signs up, send them a welcome email” then choreography is a good candidate. When we speak in terms of process names, e.g. “Your application process is at the ‘Pending approval’ stage” then it’s a good hint that we’re in orchestration territory.

How do we model an orchestrated process?

We’ve already established that an orchestrated process has both state (“Where is this process up to?”) and behaviour (i.e. state transitions). This sounds suspiciously like… a domain entity.

If we accept that our process is a domain entity, many things fall into place. For one, we can query its state, and we can instruct it to change state. It can also refuse to undergo an invalid state transition, e.g. a call to a LoanApplicationProcess.Approve(...) should probably fail if LoanApplicationProcess.CurrentState == LoanApplicationState.NotYetSubmitted.

Doesn’t process orchestration mean I need an enterprise service bus? Should I get one?

No matter what problem you have, an enterprise service bus can always find a way to make it worse.

Thinking purely in terms of domain-driven design, we already have all of the puzzle pieces we need to solve this problem: domain logic and state persistence. This sounds suspiciously like it woudld fit into the normal structure of our domain model. We presumably have a repository implementation of some sort, and a persistence layer.

When our process needs to respond to an external event, we can use a vanilla event handler to hydrate our process instance and dispatch the event to the process.

The only missing piece is when we have a process that is dependent on time, which can be solved quite easily with a metronome which hydrates every non-finished process entity and calls a .TimePasses(DateTimeOffset now) method on it.

… a facetious look at the nature of events.

Anything that happens, happens.
Anything that, in happening, causes something else to happen, causes something else to happen.
Anything that, in happening, causes itself to happen again, happens again.
It doesn’t necessarily do it in chronological order, though.

– Douglas Adams, Mostly Harmless

Principles of expressing events

• Events are immutable facts about the past.
• The system that undergoes the state change is responsible for publishing the event.
• The system publishing the event is responsible for defining the structure of the event.

I’ll deal with each of these principles individually - and slightly out of order. Please forgive the poetic licence.

Principle: The system that undergoes the state change is responsible for publishing the event.

Whilst modesty is admirable in a human, in software it is confusing. The component that has undertaken the action or undergone the state change should be the one to publish an event saying so. Our software should shout about its own doings, and not expect the town crier to follow it around.

Our code should follow the Assert. Act. Announce. pattern. Specifically, it should assert its preconditions, perform precisely its appointed task (and nothing more) and then announce that that task has been performed.

If we have some code that looks like this:

var cat = CatFactory.SpawnOne();
var mat = MatFactory.WeaveOne();
cat.SitOn(mat);

then our Cat implementation could look something like this:

public class Cat
{
    // ...

    public void SitOn(Mat mat)
    {
        // Assert
        if (_remainingLives <= 0) throw new DeadCatException("Dead cats can't sit on things.");

        // Act
        _currentlySittingOn = mat;
        mat.BeSatUponBy(this);

        // Announce
        DomainEvents.Raise(new CatSatOnMatEvent(this, mat))
    }
}

Crucially, the Cat is the one that has undergone the state change so it is the one that emits the event. (Side note: the Mat might also change state by virtue of being sat upon, in which case it should emit its own event.)

Principle: The system publishing the event is responsible for defining the structure of the event.

… and for honouring that contract.

The system that underwent the state change is the one that knows what happened. It is therefore the best placed to define the structure of the event representing that state change. Crucially, the publishing system should not attempt to cater to downstream subscribers who might desire additional information.

Consider the following event:

public class CatSatOnMatEvent
{
    public Instant Timestamp {get; set; }
    public Guid CatId { get; set; }
    public Guid MatId { get; set; }
}

This structure is quite terse but describes exactly what happened and only what happened. This is a Good Thing.

What happens, though, when a downstream subscriber wants to know the cat’s name? We end up with something like this:

public class CatSatOnMatEvent
{
    public Instant Timestamp {get; set; }
    public Guid CatId { get; set; }
    public string CatName { get; set; } // not a good idea
    public Guid MatId { get; set; }
}

What could be so harmful about that? Let’s go one further and suggest that another downstream subscriber wants to know the colour of the mat upon which the cat sat:

public class CatSatOnMatEvent
{
    public Instant Timestamp {get; set; }
    public Guid CatId { get; set; }
    public string CatName { get; set; } // not a good idea
    public Guid MatId { get; set; }
    public Color MatColor { get; set; } // also not a good idea
}

All of a sudden, we discover that our publisher will be responsible for marshalling all sorts of additional information just in case a subscriber wants it. The first subscriber doesn’t care about the colour of the mat and the second doesn’t care about the name of the cat, yet the publisher ends up being obliged to collate both every time it publishes an event just in case a subscriber wants it. This gives the publisher potentially as many reasons to change as there are subscribers - exactly the opposite of what the Single Responsibility Principle advocates.

What the publishing system should be doing is including only the information 1) about which it is authoritative; and 2) necessary to convey the essence of what happened. The system that cares about the name of the cat can then call a service to retrieve the name of the cat; likewise for the system that cares about the colour of the mat.

The publishing system is responsible for honouring that event contract for as long as agreed with its downstream subscribers. For an in-process event a refactoring could be done in a single commit, but for a business event published to a Kafka stream it might need to honour the contract for weeks, months or even years. It is the responsibility of the publisher to honour this contract for as long as its SLA specifies. (Site note: contract tests and/or schema registries will come in useful here.)

Principle: Events are immutable facts about the past.

An event should describe a thing that happened. It must have actually happened at a specific time. Events are expressed in the simple past tense.

The cat sat on the mat.

This is a good event. It’s expressed in the simple past tense. It unequivocally happened. Anything that may have happened after this event does not change the correctness of this event.

The cat is on the mat.

This sentence is in the present tense.

We could validly fire this event infinite times per second provided that there were, indeed, an appropriate cat sitting upon an appropriate mat. It would not be helpful. It would be much more helpful if we were to announce (once) at the moment that the cat were to first sit on the mat that it had done so.

The cat was sitting on the mat.

This is in the past progressive tense. It’s in the past, true, but it describes something that was happening and continuing to happen. Provided that the statement was once true (i.e. that the cat, once upon a time, sat upon the mat), the statement will always continue to be true. While a true statement, it is not helpful.

The cat sits on the mat.

Does it? When? Is it there now? Does it just generally sit on the mat? Do all cats sit on all mats?

The cat will sit on the mat.

Are we sure? How sure? Are we sure that it’s going to sit on the mat at precisely the timestamp on the event? It is a cat, after all. What if it gets hungry? Or bored?

This event is neither immutable (it might or might not happen) nor about the past.

The cat would have sat on the mat.

… but it didn’t because cats are fickle. This is not a thing that happened, therefore it’s not a good candidate for an event.

The cat should sit on the mat in ten minutes.

This is a command, not an event. It’s a valid command but it’s not a fact about the past.

Some other considerations

Commands should not be dressed up as passive-aggressive events.

We want our event publishers to observe the Assert. Act. Announce. pattern. Specifically, the publisher of an event should actively not care about whether any downstream consumers take action as a result of the event.

When an upstream system requires a downstream system to take a specific action as a result of something that happened, it should send an explicit command (either synchronous or asynchronous) to that system rather than announcing an event and then waiting expectantly.

Dinner is served, cat!

This is a passive-agressive event. The publisher of the event is waiting expectantly for their cat to come and eat its dinner, without having expressed that expectation.

Cat was requested to eat dinner.

This is also a passive-aggressive event. It expects a specific action to be taken and it is likely that the publisher of the event is waiting for that action to be completed.

Cat! Come and eat your dinner!

This is a perfectly acceptable command; it’s just not an event. It is an imperative instruction for an entity (cat) to undertake an action (come and eat dinner). It is entirely reasonable to send such a command; just not to present it as an event.

Think about your events’ granularity.

It is useful to structure events according to business events that actually happened and that people would talk about in real terms. It is likely that downstream systems will take different actions based on different events and don’t want to process “catch-all” events that they then have to further filter.

For a more serious example, consider entity-named events (e.g. CustomerEvent) that describe something vaguely related to a customer and, worse, generic CustomerUpdated or event just CustomerUpdate “events” that neither describe what happened or even assert that something did, in fact, happen.

A downstream system will most likely take very different actions as a result of a CustomerCancelledAccountEvent (perhaps sending an apology letter) than a CustomerChangedEmailAddressEvent (sending an alert email to the old address), and a different action again as a result of a CustomerConvictedOfFraudEvent (perhaps suspending shipments to that customer). If all of those happenings are wrapped up in a single CustomerUpdated or CustomerEvent then 1) too much responsibility is pushed onto each subscriber; and 2) the event payload will bloat in order to accommodate all of the different information required for all the downstream subscribers.

Statements about the future are not events.

We see many examples of these kinds of anti-patterns in transaction-processing systems.

For example, future-dated transactions are inserted into a table in the same way as past-dated transactions (strike one: not about the past). Almost invariably they are then updated with an IsProcessed flag or similar when they are actually processed (strike two: not immutable).

A friend and colleague, Steve Morris and I, have been attempting to propagate the naming of this pattern for quite some time and it’s about time I wrote about it. In the vein of the AAA pattern of unit testing, we’ve been promulgating the AAA of code responsibility: Assert. Act. Announce.

1. Assert. Check your preconditions.
2. Act. Do the thing. And just the thing. No more.
3. Announce. Shout that the thing was done.

Consider the common case of a customer’s changing their subscription level to an online service. Let’s say that the simplified sequence looks something like:

1. The customer changes their subscription level.
2. The customer is sent a notification email.
3. The customer’s billing schedule is adjusted.

We could model it something like this:

public class CustomerService : IAntiPattern
{
    IRepository<Customer> _customerRepository;
    IEmailSender _emailSender;
    IBillingService _billing;

    // ...

    public void ChangeSubscriptionLevel(Guid customerId, SubscriptionLevel subscriptionLevel)
    {
        var customer = _customerRepository.Get(customerId);
        customer.SubscriptionLevel = subscriptionLevel;
        _emailSender.SendSubscriptionChangedEmailTo(customer);
        _billing.ReschedulePaymentsFor(customer);
    }
}

There are several problems with this approach:

• It’s slow. The customer has to wait until an email is generated and sent before they can be signed up.
• It’s fragile. If the email server is down, the operation will fail.
• To add a step to the process, we need to change existing code.
• The code is resistant to change.
• The CustomerService becomes a dumping ground for all things customer-related.
• When we add behaviours to the CustomerService, our existing tests break.
• Anything can put our Customer instance into an invalid state just by modifying its properties.

If we were to add to the sequence so that it now looks like this:

1. The customer changes their subscription level.
2. The customer is sent a notification email.
3. The customer is sent a notification text message. (New!)
4. The customer’s billing schedule is adjusted.

then a couple of things happen. The first is that we need to change our existing CustomerService to add behaviour. We’re going to need to change the ChangeSubscriptionLevel method, and we’re also going to need to change the constructor to include some kind of ITextMessageSender. That means that all of our existing unit tests will immediately fail to compile.

Think about what we’ve just done. We’ve not changed the correctness of our existing code yet our unit test are failing. In other words, we’re teaching ourselves the lesson that whenever we add functionality, existing tests break. This is exactly the opposite of what we want, which is that tests only break when we’ve broken the functionality that they specify.

Enter the AAA pattern: Assert. Act. Announce.

If, instead of our CustomerService, we just modelled a customer with their behaviours, what might be different?

public class Customer
{

    // ...

    public void ChangeSubscriptionLevel(SubscriptionLevel subscriptionLevel)
    {
        // Assert. Check preconditions.
        if (subscriptionLevel == SubscriptionLevel) throw new DomainException("The new subscription level must be different to the old one");

        // Act. Do the thing.
        SubscriptionLevel = subscriptionLevel;

        // Announce. Shout that the thing was done.
        DomainEvents.Raise(new CustomerChangedSubscriptionLevelEvent(this));
    }
}

By publishing the CustomerChangedSubscriptionLevelEvent we allow downstream behaviours to be decoupled from the original action. We get several benefits from this:

• We can make the assumption that any time we are passed a domain entity, it is in a valid state. In other words, the customer entity can say no, and refuse a change that would put it into an invalid state.
• The Customer class doesn’t have to change at all when we add a downstream behaviour.
• The existing tests continue to compile without change.
• The existing tests also continue to pass without change.

It’s worth noting that the Customer class in this case is not responsible for sending an email, sending a text or informing the billing department - and nor should they be. The Customer entity’s job is to represent a customer, not orchestrate a business process.

To bolt additional downstream behaviours onto the customer’s action, we use event handlers, e.g.

public namespace WhenACustomerChangesTheirSubscriptionLevel
{
    public class SendThemAConfirmationEmail : IHandleEvent<CustomerChangedSubscriptionLevelEvent>
    {
        IEmailSender _emailSender;

        // ...

        public void Handle(CustomerChangedSubscriptionLevelEvent e)
        {
            _emailSender.SendSubscriptionChangedEmailTo(e.Customer);
        }
    }
}

This isn’t a new pattern. Udi Dahan wrote about it in 2009 in his Domain Events – Salvation post, we’ve been using it for over a decade and the Observer pattern is an original GoF pattern. At the ThoughtWorks Event-Driven Architecture Summit in 2017, a number of us started to thrash out a bit more of an opinion about what “event-driven” actually means, and the various flavours of it. Martin Fowler’s article on What do you mean by “Event-Driven”? is one of the outputs of that summit. We’re generally calling pattern that we’re using in this case event notification or event choreography.

If we want multiple behaviours, we just add mulitple handler classes; the principle being that in order to add behaviours, we just add code. We don’t want to change existing code unless the existing behaviour of the system needs to change. We do need to understand which events should be handled synchronously versus which can be handled asynchronously but there are straightforward solutions to that problem.

The pattern to remember, though, is AAA: Assert. Act. Announce.