Can domain modeling be taught?

I answer a listener's questions about whether domain modeling is a skill that can be taught.

Transcript

[00:00:00] Can domain modeling be taught?

[00:00:04] Hello, my name is Eric Normand and this is my podcast. Welcome.

[00:00:11] So I got a really nice listener question. I just saw it this morning. And I'll try to read it to you here.

[00:00:23] To what extent is domain modeling a discipline in its own right? And to what extent is it a direct extension of understanding the domain in a certain way or ways?

[00:00:36] I'll stop here and answer this one. Oh, by the way, this is from Asher Serling. Thank you so much for the question.

[00:00:44] Is it a discipline in its own right? That kind of question is the kind of question I like to skirt. When I wrote the functional programming book Grokking Simplicity, I also faced [00:01:00] similar questions. It's definitely a hard question to answer. But it's not really important because it's something that some people do that other people don't, and if you can just turn it into a set of skills that you could teach to someone or even just demonstrate. This is the kind of stuff they're doing, and that is enough to blow their minds-- to open up their minds to like new possibilities.

[00:01:32] And they start seeing things a little bit differently. And so their code is different.

[00:01:36] So is functional programming a discipline? Is it a style? All those things are not so important, but you can see that there are practices that are being done over here that aren't being done over there.

[00:01:50] And if you can help them see them , where it's safe and they can understand it better, they have a higher resolution view on it. Because if they just look at the code, they'll be [00:02:00] like, Oh, this is crazy. But if you can break it down and show the practical side of it and the before and after. You just show them all sorts of high resolution views of it, you describe it , you break it down. Then they see, Oh wow. I didn't know that that's what functional programmers were doing. I thought it was just people who liked map, filter and reduced too much, or they liked to make things complicated. That's the kind of thing that people would think of functional programming if they just saw it in the wild.

[00:02:32] Now, the second part of the question is: Is it just an extension of understanding your domain in a certain way or ways? And yes, I think that there's a large part where it's just about understanding your domain better and in certain ways.

[00:02:52] And those ways are the things that I need to teach. What are the ways? Well, the idea of looking [00:03:00] at a choice. Is it a small, medium or large pizza, that choice, how do you represent that? There are ways that are not good. So one way is you could have like three Booleans and using runtime checks.

[00:03:27] So we can talk about the problems. Why is this a big deal? I don't know if anyone would ever do that for that particular example, but I've seen it for other examples. And so if people are doing it, it means they need to learn to see why it's bad.

[00:03:42] An alternative is what I'm calling it . And so then what are the possible encodings for alternatives that you have in your language, right? Because there's now this second step where you have to encode it. And what are the semantics of those different things? Do those [00:04:00] semantics make it possible to encode this alternative? Does it make it convenient to encode that thing?

[00:04:08] These are the ways that you have to think when you're doing domain modeling. And so yes, I think it does just break down to ways of understanding. Encoding it is one way of understanding it, trying to break it down into these possible things.

[00:04:27] So a follow up question: To the extent that domain modeling is an extension of understanding the domain in a certain way, how much can that actually be taught? Meaning isn't the general ability to understand many different domains something that's hard to teach?

[00:04:46] This is a really good question and it's something I ask myself all the time. How can we teach this? How much of it can be taught? And I think quite a lot. [00:05:00] But then yes, it is hard to teach. My first answer is I can't teach it all. One book cannot teach it all.

[00:05:10] What I can do is kind of open the discussion. I say that with a lot of humility because I know there's a lot of people who have been writing and speaking and practicing Domain Driven Design. And a lot of this stuff has been thought of in the Domain Driven Design literature.

[00:05:32] But what I've found is that they talk more about the why. Why do we focus on the domain? What it means at a larger business level and the team level? To me, they've forgotten the how. How do we take a domain and actually break it down?

[00:05:50] I wanna go just a little bit deeper on the how, on the physical construction of these domain models, [00:06:00] and not focus so much on stuff like bounded context and ubiquitous language. I wanna focus on those nitty gritty details of choosing what type this thing should be or what shape it should be, and whether you use a name or a reference and things like that.

[00:06:22] And do it in a very teaching way and not a pontification way. The DDD book, the original one by Eric Evans, there's a lot of good stuff in there, but it's only clear if you already kind of know what he's talking about. It's a problem in tech books where people just kind of state their opinions on things, don't teach it in an accessible way. I want to teach it in a way to build up those skills.

[00:06:52] It's hard and there's some skills that we [00:07:00] don't know how to explain how we do it, but that doesn't mean we can't teach it. There are ways of teaching it. One way is to give a bunch of examples and a bunch of exercises because the learner needs to practice. If you give a bunch of examples and a bunch of practice with self correcting exercise , a person can build up a very good understanding of the kind of thing you're talking about.

[00:07:28] Another thing is to just point at stuff. This thing is important. You're not looking here. You need to look here. And you see it's here too. And you see it's here too. And you see it's here too. Your brain is a neural network. With enough examples, it will generalize without you ever consciously knowing what's going on there.

[00:07:50] Pretty soon they're able to point out the similar phenomenon in other places, in other examples. It's just [00:08:00] something that they hadn't noticed before. And just by pointing it out, you can actually help someone learn it. There's a whole branch of teaching theory that is called perceptual learning, where you just give examples and you force them to make a choice. You can show them an example and say, Good design, bad design, good design, bad design.

[00:08:23] And you just keep showing them examples and eventually, they will learn the choices of good design and bad design that you made, never having some verbal explanation for it. So yes, it can be taught. The hard part is assembling the examples to show.

[00:08:46] All right. I hope I've answered your question. Asher, thank you so much for asking it. I'd love to get other ones. My name is Eric Normand. This has been another episode of my podcast. Thanks for listening and as always, rock [00:09:00] on.