How to teach an essential skill in domain modeling?

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:24] So if you're working in JavaScript, you got a bunch of tools, you've got your arrays, your objects, strings, numbers, functions, just go through the list, and these are the tools that the language gives you, and you have to build something out of that.

[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:02:33] I need to teach both the JavaScript side and the Java side. I want to do the same example because motivating the example is actually quite a lot of work. So if I have to motivate two examples now it's like twice as long. Whereas if I use the same example twice, it's about two thirds to work instead of three thirds of the work. The trouble is that it still makes it much longer, right? It's one half longer to do both and maybe even more because Java's kind of verbose.

[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:04:23] And I want to encourage people that if they're using JavaScript, yes, just launch a JavaScript REPL or a short file of code, and build your model, and then build a little use case using that model and then run it. You can do it in Node and just run it right there in the command line. Likewise, you could do something very similar in Java, and really work in the medium that you are going to be doing the finished product in.

[00:04:56] Okay, so my idea now to get through this, I think I just need more information. I'm just gonna do it in JavaScript and Java, and I'm writing out all the code so that I can see what I'm working with and how I can organize it.

[00:05:23] Cuz you know, there's other questions like, do I work through the JavaScript, like step-by-step. It's a lot of explanations. But then put the Java at the end and be like, here's how you would do it in Java, and not go through all the step-by-step. Or do I do one step in JavaScript and show it in Java, like alternating that way? I think I need to see it before I can figure out what the best way is.

[00:05:54] I really think it's vital that this does not come off as, domain modeling is something you can do in JavaScript. Or, oh, you need arrays and hash map literals to do domain modeling. I really want to make sure that people can take the language that they're using and see past the basic habits to see the deeper structure and the semantics.

[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:09:36] So I really think that it's important that I hit different language groups that have different kinds of semantics. JavaScript and Clojure are very heavy on operating on hash maps. Okay. So I'm calling that data oriented. Then there's the Java, C Sharp. Those have very class oriented.

[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!