IA as Domain Driven Design

Quietly, unbeknownst to us, developers have been teaching themselves to do information architecture. I say quietly, but they’re not being all that quiet about it. There are books, presentations, even entire conferences dedicated to it, and we had no idea, because they’re calling it something else: Domain Driven Design. This wildly popular software approach emphasizes matching technical design to the business and requires developers to create controlled vocabularies, model the flow of information through business units, and interview experts to uncover their mental models before they get down to coding. This is all the stuff that IA is great at, and there’s a whole new set of people out there desperate for our help.

If you’ve ever heard the phrase “ubiquitous language” or “business domain” from a developer, or you’re just frustrated with the constant discourse on design “getting a seat at the table,” come learn how to translate IA work into terms developers are already excited about and how techniques from Domain Driven Design can uplevel your IA practice.

Deck

In the 1950s, as the Cold War got going, the United States decided it needed a proper intelligence agency to counter growing threats. The brand-new CIA needed to scale up, hiring the best people as quickly as possible for a job none of them had ever done before. They settled on a protocol.

Male recruits changed into army fatigues and engaged in a mock-sabotage exercise in the basement, pretending to blow up a bridge with only the contents of their pockets or something similarly Jason Bourne-like.

For female recruits, however, they divided them into small groups, and asked them to work together to create an indexing system for correspondence. They wanted to see how they collaborated, and they were interested in the quality of the systems they made –

Which facets did they identify? Would their system be useful and usable?

This struck me, because it’s not a bad interview task. I might use something similar to hire junior IAs. I DID use a similar exercise to teach undergrads in an intro IA course. This is a good basic way to figure out how candidates think about information. Most people can think about indexing them by sender and recipient, probably, but did they account for different names for the same person? Did they go deeper and think about dates, locations, sensitivity, subjects? Did they balance the value of things that might be useful against the effort of implementing them in a system? This is a great, simple exercise.

So, the CIA was interested in that.

But also, how did they react to being underestimated? Of course, part of the reason the CIA assessed how well women who could speak four languages and had graduated from the most prestigious schools in the US could do clerical work was that they were likely going to be doing clerical work, a task far below their skill set. But not all of them did. An IA test, among other things, also found good spies.

Now, let me be clear, I am not here to stan the CIA.

But I read this story recently, and I couldn’t stop thinking about it. There’s something about that that makes sense to me, as silly as it is. I think there’s something to asking people to think through a system from multiple perspectives, separate the information resources from the way they’re represented, and unearth implicit structures in a body of knowledge together.

We know that these are not universal skills. I think about this a lot, because, to be silly about it, IA work does feel like spy work sometimes. It relies on integrating yourself into new contexts, using a skill set that most people don’t even realize exists, and convincing groups and systems to disclose their innermost workings. When you do a great job at it, nobody knows, because it feels obvious and inevitable. We’re so used to working in the shadows that it can feel odd to even have anyone notice we’re doing it.

This happened to me few months ago: Our head of engineering came to me and said, “I’ve never worked with IA before, but your team are clearly domain experts in the training and documentation space.”

And I had to gently explain that no, we’re not. We’ve done this for all the domains we’ve worked in. We also know a lot about door locks and deep space telescopes, or at least did for a while when we were working on projects that needed us to.

I saw a lightbulb go off for him. Not because he newly realized that was a needed skill, but because he had found it in an unexpected place.

See, he (and engineering as a whole) has spent decades dealing with a difficult problem: The purpose of a software system is to be a solution to a business problem, but engineers are learning the business’ domain as they write the code, only really getting familiar with a domain as the project is completed. This leads them to make invalid assumptions, which can go very deep, and make it extremely difficult (and expensive) to fix later. If you build a feature based on bad assumptions, it can be almost impossible to remove or refactor it even years later.

This is a huge problem and has led to lots of tools and cheat sheets over the years, like the famous “Falsehoods programmers believe about time,” which specifies things as (seemingly) obvious as “Years have 365 days” to ones that would stump most of us like “Leap years occur every 4 years.” There are similar lists for names, geography, addresses, gender, and more. Because every single thing in the world is complex. These lists of falsehoods exist for concepts that many programmers encounter, but I could come up with a similar one for the business that I work in, and I bet you all could too.

So, a process called Domain-driven design] originated, about twenty years ago, to address this problem, and make sure developers got familiar with the details of their domain FIRST. Our engineering manager was adamant: Our IA process of defining terms and developing models was the essential first step of “Domain-driven design,” and we were better at it than any developer he’d ever worked with.

On the surface, all that domain driven design asks for is that the technical design be driven by a nuanced understanding of the business domain. To do that, you figure out a few key things.

First, you figure out the business domain (and then because it’s turtles all the way down, its subdomains). What is the business doing? These are tricky because they can change sometimes, and almost all businesses have several. You don’t have to be as heterogenous as Siemens, who will happily sell you a train and a CT machine, to have several domains going on.

If we’re a shipping company, we probably handle logistics, but we also might have retail stores that have to be managed, and we have to process payments so people can give us money, and we also have to manage a fleet of trucks. This isn’t exhaustive, even a business that does one main thing still has lots of domains necessary to make that happen.

And this is common sense, but not all these sub-domains are equally complex, and not all of them are places where we’re trying to be significantly different from our competitors. So it’s good to make that explicit and say, “Payment processing is really complex, but we’re not competing as a payment processor. We don’t even want people to think about that part of their experience with us.” Whereas maybe how well we handle logistics is where we’re really competing, so it’s both complex (or everyone would do it) and it’s a place where we want to be notably better.

DDD has us group these domains based on this interplay of complexity and business differentiation, into generic, supporting, and core subdomains.

This terminology isn’t very important for our purposes. but the idea is that you don’t want to put a lot of effort into the generic stuff. Unless we’re Stripe, we’re not reinventing payment processing. We need to use some standard software that someone else who knows what they’re doing is developing.

So, we want to focus our efforts on what are called core subdomains, places that are complex AND differentiate our business from its competitors.

Because that’s going to help us figure out where to focus to have the most impact.

Next, Domain driven design asks us to use what is called “ubiquitous language.”In my experience, this phrase is a dead giveaway whoever you’re talking to is onboard with domain driven design.

Ubiquitous language means that everybody involved, business, technical, and systems, uses the same words for the same things with the same meanings all the time. So we don’t refer to the thing we sell as a “product” sometimes and a “SKU” others. We choose one term and use it consistently. I feel like this is one that I don’t have to convince you all on, because this is the bread and butter of IA.

This process of untangling uncontrolled language to identify stable concepts

Like in this example from David Laribee from a talk about domain driven design

Could be used straight in object oriented UX training.

I wasn’t even looking for it, I was just procrastinating on LinkedIn while writing this talk, and I saw this post from IA Nathaniel Davis about how essential IA is to solving problems like this. This is a ubiquitous language problem!

Unsurprisingly, I guess, figuring out “what are the things in this experience? What are they called?” is essential for all kinds of reasons.

The third major idea from Domain Driven Design is that programmers need to understand the system in terms of realistic, meaningful objects, they have terms for these like “entities” and “value objects.” Which we mostly don’t have to worry about. But the idea behind them is important.

This idea of identifying what the things are in an experience, is not new, or revolutionary, it’s just important. DDD particularly values these entity maps because of the context they provide for developers.

A lot of us have probably made something that looks like a content or object model, or entity map.

Maybe you’ve translated that into something that looks like an ERD

And if we’re very lucky, something similar ends up implemented in a schema. The process leading up to the schema is important because bad things happen when programmers get too dedicated to primitives, meaning just treating things like generic numbers, strings, etc.

Treating a dollar amount like a number, for instance, MIGHT work sometimes, but it risks hiding a lot of essential behavior.

If we know it’s a dollar amount, that tells us some things: It will probably have a decimal, a dollar sign will go in a certain place, etc. But there are questions we can’t answer without knowing more about it: Can it be negative? How many decimal points does it go to? Identifying that this dollar amount is an account balance implies one set of rules, identifying that it’s a gas price implies another.

Developers badly need to give the things they’re working with meaning and context so they can make better assumptions while they work.

So, these questions Domain Driven Design is asking developers to grapple with are clearly important, and I suspect, they’re familiar to most of us, but that doesn’t mean they’re easy. And, computer science education and early-career training for developers doesn’t teach them how to do any of this. It’s something you’re expected to learn on the job.

Pretty much any search you do for DDD has a bunch of people asking, “Is it me or is this REALLY hard?” sometimes the part that feels hard is the later technical implementations, but a lot of times, it’s terminology, it’s figuring out what objects your experience has. It’s the IA. And these posts are full of responses saying things like “It’s only really possible to have good IA with brand-new greenfield projects.” Which we all know isn’t true.

And this is the problem: This method is extremely popular, developers are either trying to do it or feel like they ought to be, and they are STRUGGLING. So there’s a whole industry of books, conferences, consultants, articles, training, coaching, everything teaching engineering teams how to do this. I counted 10 upcoming DDD conferences in 2024 alone.

Looking at this, I can’t help but realize, the developers are teaching each other how to do information architecture.

Now, I know that there’s not a total overlap. There are plenty of technical considerations to DDD that IAs aren’t going to be interested in, and there are whole aspects of IA that aren’t reflected here. But please, indulge me:

Here are some talks from DDD Europe 2023 that are up on YouTube right now. I could imagine every single one of these on the schedule here.

So I see an opening here to go undercover. Because it’s not just that “this is IA under a different name.” Even though I think a lot of it is.

Because we are well outfitted! Our education, mentors, and experience have given us a whole set of special gadgets to do this work, CUNNINGLY CONCEALED in our humanities degrees. Specifically, I think we bring a few really important things.

First, we know a little bit about a lot of things and know how to learn more quickly. Effectively, we are experts in becoming experts. We even think about this as an essential aspect of our practice. Joan Hua gave a great talk earlier this week about getting up to speed in a complex new domain. Many others have talked about how they learned enough to make sense of AI or medical testing, or any number of other complex spaces.

We’re great at getting mental models and assumptions out of people. So frequently, when I watch non-IAs facilitate a conversation about a domain, they take the first answer they’re given, without pushing on it or checking it.

“Does a course always have an instructor?” They’ll ask. “They pretty much always have someone in charge,” a stakeholder will answer, and they’ll move on. “Pretty much?” “Someone in charge?” That’s not always. Is an instructor the same thing as a person in charge? Is there only one? Is it the same person throughout the course’s lifecycle? That’s something we have to dig into, to figure out.

Dan Klyn has a great diagnostic tool: He says that you need IA wherever complexity is being lost. I didn’t get it at first and was skeptical, I was like “Man, that’s a hard sell. Everybody wants simple” But he’s right, because simple isn’t valuable, simple isn’t realistic. And I think that’s what’s at play in situations like this. A facilitator asked a question and a stakeholder gave an incomplete answer, that’s fine, people do, but by taking that answer instead of getting to the models and assumptions beneath it, that complexity can’t be translated into the system. It’s lost.

Lastly, one of the ways we get that expertise and elicit those assumptions is by taking things up and down the ladder of abstraction. This is a fancy term for the idea that a single concept can exist at many points along a continuum of concrete to abstract. You can have an extremely concrete example, or you can have an extremely abstract principle for a similar space.

We can concretely have the specific page in a specific place in our sitemap and we can have the abstract design principles for our navigation.

Pay attention to yourself or a talented colleague facilitating a discussion sometimes, and I bet you’ll notice continual movement up and down the ladder, to take an example, abstract it into an idea or hypothesis, and see if it holds true in another example. We do it all the time (I’ve been doing it just now.) This is an absolutely essential skill to taking a collection of data and turning it into a model that everyone can understand.

So, I feel like it is important to caveat that I have not taught you all of DDD in fifteen minutes. There’s a lot more vocabulary. There’s a whole process of “tactical” DDD where you get into the nitty gritty of software design, but frankly, I don’t think we need to be too interested in that.

It’s this first exploratory part. That’s what needs us to become domain experts quickly, elicit mental models and assumptions, and move up and down the ladder of abstraction to create the shared understanding that will give rise to a domain model, ubiquitous language, and nuanced entities, value objects, etc.

So that’s all very well and good to say, but what does this look like?

Do the same work, share it with new people. When you make controlled vocabularies, concept models, content models, whatever, share them with technical folks too, a lead developer, a technical architect. Not everyone will bite, but you can begin to show your expertise in this space, and they’ll know they have someone who can do this.

Read a couple of books and add a few terms to your toolbox, see if it sparks anything for the technical people you work with.

These might get a response, they might not, but they function as code phrases to indicate to colleagues who might be trying to do DDD that you’re already figuring things out.

And I think that’s important because, historically, IA is seen as a specialty in Design. Which is fine, we all know better than to say there’s one single right way to classify things.

But my intellectual heritage is in library science, which the theorist Marcia Bates classifies as one of the information professions, which, like education and journalism, operate orthogonally to other disciplines. The idea here is that you can have information science in the context of the arts, humanities, or social sciences which maintains intellectual continuity, because the domain expertise is in information science, not in the individual disciplines. In the same way that when you want a great spy on TV, you don’t go out and find a spy, you hire an actor, when you need to do the IA for a space, you need an IA, not a domain expert.

This has a funny effect, it’s so easy to watch people in other disciplines do things and go “Ah, that’s IA!” In a horrifying reminder that just as you can see other people, they can see you too, it’s really easy for other disciplines to look at what we’re doing and see product strategy, or software architecture, or product design. That can make it hard to have ubiquitous language about ourselves, instead of saying “yeah sure, we’ll call it your thing.”

And frankly, I think this talk will not help that, but I’m not really sorry.

Mostly because I’m a sucker for what works.

Every time I see a call for conference proposals go out, I am like, “This is my moment. I’m going to come up with such a cool theoretical idea, it’s going to blow everyone’s socks off”, and every time, I do not even try to do that. There’s an element of ego here, I know, but also temperament. My father was a builder and mechanic, the kind of guy who’d overhaul your engine and have three parts left over, and tell you that you didn’t need those anyway. I suspect, for better or for worse, I may be that kind of information architect.

I feel a strong affinity for the Domain Driven Design process, possibly because, I have been assured by the engineers I work with, that most engineers are duct-tape and baling wire people at heart as well.

So, I’m sharing this because I’ve found that this works, for my definition of “works,” which is, it keeps putting food on the table and lets me do the parts of my job I like best.

I love getting in a room with people and making them decide whether they all know what a “customer” really is.

But also, I think it “works” in that it creates new spaces where this discipline that I love is vital. It’s gotten us begged for help in technical architecture discussions. It’s gotten us to be the only product team consulted in org designs. It’s opened up tons of doors. There are also aspects of IA that I think have been figured out in Domain Driven Design that we haven’t gotten to yet. I think it’s made me a better information architect. I’m never going to be sorry about finding new ways to do this work and make it important.

But, clearly that tendency to slip undercover a little too easily has its drawbacks. It can make it hard for us to identify each other in the wild, it can make it hard to stay motivated and keep the critical distance we need to do good work.

Which is why I’m so grateful to have spaces like this. Because, one last important thing about ubiquitous language is that it doesn’t ask you to try to fix the whole world. It doesn’t ask you to make everybody across a whole company change the way they talk. You figure out where you NEED to be able to communicate clearly and use language to carve out a shared space in which to collaborate better. For me, it’s enough that we have this space, here, those collaborators are us. Thank you.

Resources

Bates, M. (1999). The Invisible Substrate of Information Science. Journal of the American Society for Information Science and Technology, 50(12), 1043–1050.

Ddd-crew/welcome-to-ddd. (2024). Domain-Driven Design Crew. https://github.com/ddd-crew/welcome-to-ddd (Original work published 2020)

Falsehoods programmers believe about time. Retrieved April 17, 2024, from https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time

Khononov, V. (2021). Learning Domain-Driven Design (1st edition). O’Reilly Media, Inc.

Laribee, D. (2007). Ubiquitous Language . https://www.flickr.com/photos/laribee/407289176/

Mundy, L. (2023). The sisterhood: The secret history of women at the CIA (First edition). Crown.