How to teach an essential skill in domain modeling?
This is an episode of The Eric Normand Podcast.
Subscribe: RSSApple PodcastsGoogle PlayOvercast
One important skill in domain modeling is learning to see the semantics of your language, past the habits you've developed. To do that, it helps to see the same example in multiple languages. So how do I show examples in multiple languages without expanding the size of my book?
[00:00:00] How do I teach one of the most essential skills in domain modeling?
[00:00:09] Hello, my name is Eric Normand, and I am welcoming you to my podcast.
[00:00:19] I've been working on my book diligently. I wake up early every morning and. Pull out the papers that I'm working on and spread them out and just write. And today I hit a stumbling block.
[00:00:44] I realized I wanted to teach the same example in two different languages. The reason I want to teach it in two languages is that one of the very important essential skills of domain modeling is to be able to understand your medium, the language itself, and its semantics, and use the features of that language to encode the domain.
[00:01:48] I don't want to teach. This is how you build a domain out of arrays and objects. That is not my goal. My goal is for people to see a deeper structure than the features that their language gives them and look for ways to express that structure within their language. That requires jumping to another language that has much different semantics and showing how it's done somewhere else.
[00:03:16] What a lot of people do when they write these books is they don't use a programming language at all. They go to something like UML and they say, we're going to describe this domain in UML and leave it up to you to translate it into whatever language you want. The reason I don't want to do that is that I think that going straight to your language is important because you wanna be able to run the thing and use it and test it, and you get a lot more feedback, a lot more information about the feasibility of your model.
[00:03:58] If you go straight to your language and build a little test, a little program, a little prototype, something to show some use case right away, you wanna play with it. You can't play with uml. You can look at it, you can print it out, you can look at it in different views and stuff, but you can't really run it.
[00:06:30] I'll just give an example of what I'm talking about. We often think of interfaces and classes that implement those interfaces in Java as basically a way for it to get polymorphism. I wanna be able to swap out the implementation of this thing, so I'm gonna make two classes and have an interface.
[00:06:56] That's a perfectly fine use of it. There's something deeper that I want people to see, which is that an interface, with its different classes implementing it, is actually a way to implement an alternative. This alternative represents a decision among different choices and each class can represent one of those choices.
[00:07:26] What's an alternative? The different pizza toppings. Do you want olives or mushrooms? Or even better is the size of a pizza. Do you want small, medium, or large? You choose one out of those three alternatives. You make a selection of one of them, and the alternatives are, as a collection, the different possible selections you could make.
[00:07:55] The collection of alternatives is the interface with the three implementations, a small, medium, large. Okay. Let's just say we use classes for this. I'm not saying that's the best way, but you could, you can have a class for small, a class for medium, a class for large, and the interface would define the common methods on those classes.
[00:08:22] And then any particular variable of the type Size (so size is the interface) could be assigned one of those three things. So that would represent the choice that you've made in your pizza.
[00:08:44] Now this is not the way most people approach the problem of modeling in Java. They think more, I got a class and it has has-a relationships with other classes, and I want people to see it in a much more structured way. You are able to construct an alternative using the constructs of the language.
[00:09:09] There's other ways. You could use an, Enum. But this is one way, and it's a choice you can make for how to represent alternatives. Likewise with combinations I want to show in Java, look what Java the language gives you which gives you the same structure that you need to represent combinations.
[00:10:06] And then there's a third type that uses a Hindley-Milner or some other kind of abstract data type kind of type system that lets you maybe more directly hit alternatives and combinations. So for instance, in Haskell, alternatives are easily written with discriminated unions and combinations with record types.
[00:10:39] So like these things are pretty clearly translated into Haskell. So I don't feel like I need to dwell too much on it, especially since most people will not have a lot of experience with Haskell. But you can do a lot of the same stuff in TypeScript. So I'm probably gonna focus on that one.
[00:10:58] A book is a linear medium, so you kind of have to choose a linear sequence of stuff of how it's gonna show, and you don't wanna lose people, you know, probably what I'm gonna have to wind up doing is a lot of forward references like, Hey, if you're not interested in Java right now, jump ahead to page 75.
[00:11:27] I think with those kinds of very pragmatic choices of layout and forward references, I can make it all work. It's gonna come down to the detail. There's no one right answer that I can just choose and it's going to work, which is why I just decided to write out all the code and start trying to put it together.
[00:11:56] My name is Eric Normand. This has been another episode of my podcast and as always, rock on!