(Data) Ownership, Boundaries, Contexts – what do these words mean?

In the last months, we started to use these terms more and more at my company without discussing the concepts behind them. One day I was asked, “What do you mean by data ownership?” 🤔 The question made me realise that I don’t know how much of these concepts are understood.

These terms refer to sociotechnical concepts (some originating from Domain-driven design). They refer to one possible answer to the question: how can a product be improved and maintained in the long term? How can we avoid hunting for weeks for bugs, understanding what the code does, finding out what it should do, and hoping that fixing one issue does not lead to a new problem? How can we continue having fun instead of becoming more and more frustrated?

Real digital products address needs which were fulfilled earlier manually. Companies which survived the first years of testing the product are often innovators in their market. They have chances to stay ahead of the others, but they have the burden of solving all questions themselves. I don’t mean the technical questions; nowadays, we have a considerable toolbox we can use. But all the competitors have that toolbox too. The questions to answer are how to organise in teams and how to organise the software to reach a steady pace without creating an over-complicated, over-engineered or over-simplified solution.

How to get a grip on the increasing complexity built up in those years when the only KPI that mattered was TTM (Time-to-Market)?

Years ago, the companies creating software to help automate work answered this question with silos around the architecture: frontend, backend, processing, etc. In the meantime, it became clear that this was not good enough.

Engineers are not hired to type code but to advise and help to solve problems. 

This means they should not belong to an engineering department anymore but be part of teams around different topics to handle: marketing, search, checkout, you name it. These are sub-domains or bounded contexts (depending on the importance of the subject, more than one bounded context can build the solution for the same sub-domain). These contexts and their boundaries are not fixed forever because the context changes, the market around the company changes, and the needs change. The people involved change and, finally, the effort needed changes. The best way also to define them is to take a look at how the business is organised (sales, marketing, finance, platform, developer experience, etc.) and how the companies using the product are organised (client setup, client onboarding, employee onboarding, payroll period, connected services, etc.). By aligning the software and – to get the most significant benefit – the teams to these sub-domains, you can ensure that the cognitive load for each team is smaller than the sum of all.

What are the benefits?

  • The domain experts and the engineers speak the same language, the ubiquitous language of their bounded context, to use the DDD terms.
  • The teams can become experts in their sub-domain to make innovation and progress easier as the problems are uncovered one after another. They can and will become responsible and accountable about their domain because they are the only ones enabled to do so.
  • Each team knows who to contact and with whom to collaborate because the ownership and the boundaries are clear. (No long-running meetings and RFCs anymore by hoping to have reached everyone involved).

What does data ownership mean in this case? Data ownership is not only about which team is the only one controlling how data is created and changed but also the one controlling which data is shared and which remains implementation detail. This way, they stay empowered and autonomous: they can decide about their experiments, reworks, and changes inside their boundaries.

Data ownership also means process ownership. 

It means the team which owns the data around “expenses”, for example, owns the features around this topic, what is implemented and when so that they are involved in each improvement or change regarding expenses from the beginning. This is the only way to respect the boundaries, take responsibility, and be accountable for all decisions around the software the engineers create.

Applying these concepts can’t be done overnight, mainly because it is not only about finding the (currently) good boundaries but also shifting the mindset from “let me build something” towards “I feel responsible for this part of my product”. It needs knowledge about the product and a lot of coaching and care. But finding the boundaries to start with should be doable in case of a product already established on the market and with a clear strategy. The alternatives are silos, continuously increasing cognitive load or the loss of an overview and local optimisations.

DDD Europe 2022 Watch-List

I attend conferences and open spaces for more than 15 years but I can’t remember ever being keener to go to a conference than the DDD EU this year. But I still haven’t imagined that my list for “watch later”-videos will be almost as long as the number of talks – including the ones from the DDD Foundations (2 pre-conference days).

I was so full of expectations because I would be a speaker at an international conference for the first time and the opportunity to meet all those wonderful people who became friends in the last two years! (I won’t even try to list the names because I would surely miss a few). The most often repeated sentence on those five days wasn’t “Can you see my screen?” anymore but “Do you know that we never met before IRL?!” 🤗

This was only one of those great evenings meeting old friends and making new ones 🙂 (After two years of collaboration, the Virtual DDD organizers have finally met too!)

But now back to the lists:

Talks I haven’t seen but I should:

  1. DDD Foundations with clever people and interesting talks which should/could land in our ddd-crew repositories. (In general, the sessions are not too long, I will probably browse through all of them.)
  2. Main Conference

Talks to revisit

This list is not the list of “good talks”; I can’t remember being at any talk I wished I wouldn’t. But these here need to be seen and listened to more than once (at least I do).

Domain-Driven Design in ProductLand – Alberto Brandolini

Alberto speaking the truth about product development is exactly my kind of radical candour.

Independent Service Heuristics: a rapid, business-friendly approach to flow-oriented boundaries – Matthew Skelton and Nick Tune

The tweet tells it all: an essential new method in our toolbox

The Fractal Geometry of Software Design – Vladik Khononov

Mindblowing. I will probably have to re-watch this video a couple of times until I get my brain around all of the facets Valdik touches in his talk.

Sociotechnical Systems Design for the “Digital Coal Mines” – Trond Hjorteland

This talk is not something I haven’t understood – I understand it completely. I will still re-watch it because it contains historical and actual arguments and requirements for employers on how they have to re-think their organizational models.

This is the longest list of videos I have ever bookmarked (and published as a suggestion for you all). Still, it is how it is: the DDD-Eu 2022 was, in my opinion, the most mature conference I ever participated.

At the same time, there is always time for jokes when Mathias Verraes and Nick Tune are around (and we are around them, of course) 😃

DDD is not a goal but a means

DDD (Domain-Driven Design) is “only” one essential building block that promises evolutionary software, a software that won’t let you down in a few years or after a few thousand lines of code.

That’s it. I could stop here, the title and this short description tell everything. But is this true, can everybody reading this relate to that? Is it helpful? I don’t think so.

During the last year, I often heard the question “how can I introduce DDD in my company?” – mostly meaning “in my dev team”. It is time to answer this question now.

Misconception number 1: introducing DDD as a goal

Misconception number 2: DDD is a dev thing, and after the devs “fix this” by applying all the patterns, all problems will disappear – and they will live happily ever after …

Let’s imagine a successful company sitting already on 1m lines of code, a lot of customers, a few teams, possibly working in silos, having frontend and backend development split. Or a younger company but with the same organization, the only difference is the effort needed to change things. This company has an agile development process (with sprints and “stories” and one Product Owner pro team etc.), but they observe that every new feature takes longer and longer. A few devs have read about DDD, read the Blue Book, and convinced one of the backend teams to introduce DDD. The company agrees to let them do it because they hope that everything will be easy and fast and bug-free afterwards. So everybody is happy 😊

Fast-forward a few months: now we are at the point when the source code owned by that team was restructured nicely, with value types, entities, aggregates. Ok, the Rest API is unchanged because the frontend team is already using it and they were not involved. But the business logic is cleaned up. The names, the language were defined by the devs – DDD is a dev thing, isn’t it? The development process didn’t change either: they get requirements to implement things without including anything built by the frontend team, the part the customer sees. For this reason, the refinements are not about customer needs but API calls and frameworks – just like before the rework towards DDD.

JIRA 1234: Please add this new flag “withVAT” to the API call generating the invoice (sounds familiar?)

What is new? Frustration: the PO does not know why the devs are asking for more and more details, and the developers don’t understand why the PO does not get the meaning of aggregates and value types, etc.

Refinement: “we cannot add it to that API call, the VAT decision belongs to another aggregate! ;( ”

And what else is new? Maintaining those API routes becomes harder and harder because they do not follow the business structure but are kept as an Anticorruption Layer between the frontend and backend (team 😉).

I am sorry if I am disappointing you, it is not my intention. It is the opposite actually: to save you from this frustration after having invested so much energy and maybe extra hours to get everything perfect.

What is DDD: a paradigm, a rule set that helps you to build evolutionary software. Like Mathias Verraes says

This can only be achieved if DDD stops being a “dev-stuff” and starts leading to a common way to discuss features, behaviours, and capabilities.

And why not? DDD means not only aggregates and value types; the essential component is the ubiquitous language used in your domain by the business people, by the customer. And apropos customer: DDD aims to solve the customer’s problems and be known in the teams applying DDD. Why not create a whole team handling those needs, from the UI (or even UX) to the delivery? (this move would also change the “somehow agile” development process in a real one, based on feedback and experiments instead of a prepared backlog covering the next three months)

We live in a great time: the accumulated knowledge and the evolution of the software industry in the last 25 years give us anything we need to build resilient, sustainable and maintainable software that won’t “die” slowly if we are careful and happy to learn. What do we need?

  1. Visual modelling techniques to discuss and learn the business (like Event Storming, Impact Mapping, etc.)
  2. Crunching and defining stories aiming to solve customer needs, always with the Ubiquitous Language (like User Story Mapping, BDD)
  3. A paradigm to make decisions based on the Business Domain, not on hopes or wishes (strategical DDD to write the right code)
  4. A guide for organizing the teams to achieve good teamwork, less cognitive load and smooth development process (Context Maps from DDD)
  5. Open feedback culture to create psychological safety
  6. A set of patterns to organize the code (DDD again)
  7. A bunch of practices to write the code right: TDD, refactoring, pairing, mob-programming
  8. Trunk-based development (aka Continuous integration) and continuous delivery to reduce the lead time (the time from the idea to the usage, also to the possibility of feedback) and to reduce the MTTR (Mean Time To Recovery)
  9. Mature 3rd party services to fulfil all the other needs when offering digital products. Now we can focus entirely on our business proposal (AWS/Azure & co, Observability, etc.)
  10. The readiness and willingness to learn the business we want to improve and the corresponding company culture supporting this.

This list is my Silver Bullet. All items on it are essential, and all of them exist. Most of them had a significant value for themselves but the sum of them? Wow, they give us a real chance in this rapidly changing world with all its competitors running after our slice of cake.