Introduction

[00:00:00]
>> Mike North: Welcome to Domain Modeling for Humans and AI. My name is Mike north and I'm a principal staff engineer and product architect at Stripe and I've been a front end master's instructor for over 10 years. Today I'm going to be talking to you about taking a complex problem, studying it, working closely with domain experts and AI agents that you're using to sort of structure your code and define your architecture.

[00:00:26]
And how do we take those complex business problems and translate them into manageable units of code that are self contained, where you can evolve over time quickly and easily as the requirements of your software change. So what am I focusing in on here? What is domain modeling and why am I here to talk to you about this?

[00:00:47]
A big part of what I do at Stripe is I work closely with teams to make sure that the foundational building blocks we are creating layer up in a way where we can offer low level and high level things and we don't end up having to change our APIs all the time and change our products all the time.

[00:01:04]
So at the lowest level you can think we have the concept of money moving between two places because Stripe is at its core a payments processing company. On top of that we have this concept of a payment with a payment method and you can layer up and up and eventually you get to these drop in checkout forms that are sort of turnkey and ready to go.

[00:01:26]
And they have concepts like shipping options and all of that. And so being able to really think about all of those building blocks and how they layer up is a valuable skill. And Stripe really focuses in on this. Part of this is involving is studying your problem space to discover the key entities, their relationships with each other, and any constraints that are at the essence of the problem that you're trying to solve.

[00:01:51]
Then of course the process of taking that mental model and translating that into a software architecture. In this course we're going to be talking a little bit about domain driven design. Now this is a 20 year old concept. There are many good books about this. Eric Evans has a great book on this topic.

[00:02:13]
We're going to borrow some ideas from this that are particularly useful. Like any software architecture concept, you don't want to be adhering to these ideas too rigidly. You should think about them as tools in the toolbox and you pull them out when they're useful to you. But there are a couple gems that are at the core of domain driven design that I think every software engineer should be applying.

[00:02:37]
Particularly in a world where we are increasingly using agentic coding tools to Help us author software. You're collaborating with product owners and customers, and you're collaborating with an AI as well. If you bake the same language and the same concepts into your code as the way the business is referring to these things, you have a better shot at working together collaboratively to develop this solution, even though you're the person that's writing the code.

[00:03:07]
Another point here, why domain modeling is important, at least for me, this represents a part of the engineering career ladder. So you can think of becoming a staff engineer as learning how to deal with technical ambiguity very well. That's often part of what it means to be a staff engineer.

[00:03:30]
Someone takes a well defined problem and gives it to you, and your job is to sort of figure out like, all right, what frameworks are available, what libraries, what off the shelf tooling can I use? It's sort of up to you to define how that solution takes shape.

[00:03:48]
Domain modeling is a great tool for handling business ambiguity, and that is ambiguity in the problem space, not the solution space. So if someone just gives you a vague problem like, I've got a video course website to teach front end engineers, how should I set this up? What do people need?

[00:04:12]
What are the important entities that are at the essence of solving that problem in any meaningful way? This is a really important part of growing your career at that more senior level, as sort of the lines between product manager and engineer start to blur together a little bit and you start to think about like this architect track of your career.

[00:04:38]
So why do I feel like domain modeling is a useful concept to teach in TypeScript? Well, TypeScript types are incredibly expressive. They're not the most expressive in the world. Like if you look at Rust, they have this concept of lifetimes, and right in the types, you can see some representation of Are you allowed to mutate this object that's passed to you or not?

[00:05:01]
TypeScript can't do that because underneath it is the JavaScript programming language and we don't have those concepts. But TypeScript strikes this really nice balance between being incredibly expressive and relatively simple to read, as well as being widely used. Which means it doesn't matter if your company is using protobufs or JSON schemas, or whatever representation you choose for representing contracts between system components of whatever you're building.

[00:05:28]
Usually you can start with TypeScript interfaces and types, and you can generate whatever you need based on that. So increasingly this is being used as sort of a source of truth for shapes of objects, contracts between things, even public APIs. There are some nice frameworks like, I think it's type API, that really let you use a set of TypeScript interfaces as the source of truth, and then you can generate SDKs based on those types.

[00:05:58]
So to study domain modeling, we're going to need a complex problem space to dive into. Selfishly, I'm going to have you all work with me to solve a real problem that I have. I have a fairly substantial vegetable garden, and here it is. I took a picture a couple days ago before I flew out to Minneapolis to film this.

[00:06:20]
And you can see I've got a lot of these metal things here. These are called raised beds. So they're just like, metal sort of bins. They don't have a bottom. And you fill them with soil, and you put some rocks in the bottom so they drain well. But, like, ultimately, you're planting things in them.

[00:06:37]
So you can see here, like, I've arranged them, you can see a couple little, like, these are tomato plants that are growing, and I've got close to 40 of these things now. It's a lot to manage. The story starts with figuring out what kind of seeds you wanna order.

[00:06:57]
And once you start ordering seeds from some of these companies, they will send you these catalogs where it's just like this one here. The whole seed catalog is probably, you know, 2 inches thick. And you can flip through this and see, like, every variety of tomato you could ever imagine.

[00:07:14]
And you order seeds, and then you end up with a collection like this. And it's a lot like, this is a collection that I've amassed over maybe three, four, five years. Some of these are old, which means they're less likely to be effective. Right. It's not food that expires necessarily where it goes bad.

[00:07:35]
But the older the seeds are, the less likely they are to work. And so figuring that out is challenging. These seeds all need to be. They turn into plants which want to go into the ground at different times, right? Some of these, they're fine to plant in the dead of winter.

[00:07:52]
It's totally fine. Like broccoli, you can do that. But sweet basil with really soft leaves, that if it gets anywhere near a frost, it's gonna absolutely get wiped out. And so just figuring out, like, when you plant things, what's still good to use? How far apart do you plant these things?

[00:08:13]
There is a lot of complexity here. After I start with the seeds, like, during the winter, I have these little hydroponic bins where I drop seeds into each of these Little baskets. There's a little growing sponge in there, and you put a seed in, and it'll grow purely in water.

[00:08:31]
So there's water in this black bin and you put some nutrients in there and it'll grow. So now we have, like, an additional level of complexity here. Like, these have to sort of get started indoors at the right time so that they go outside whenever it's right for the plant, whatever that means.

[00:08:48]
We're gonna have to figure that out and model that somehow, and then they get planted outside. And you can see here, when I do plant these, I separate plants by some certain distance here. So this is a zucchini plant. It's going to get very big, and these are little peppers, and they'll stay relatively small.

[00:09:08]
And so, like, how far apart do we put these things? There are a lot of properties of these plants that we need to model if we're going to solve the problem of organizing my raised beds and my seed collection effectively. So we're gonna work on a piece of software today to make this a lot easier.

[00:09:26]
And we're gonna apply domain modeling in order to keep the complexity contained. We're gonna have some business rules, like what should be planted next to other things, or how far apart should things be spaced. And we're gonna see how it's easy to contain this business logic and make it modular so that hopefully you can see that over time.

[00:09:46]
If we were to add 20 rules to this, like, how much water does the plant need? How much sunlight does it need? What kind of fertilizer should it be using? Like, all of that could be modeled and added onto this in a way where the overall complexity of the software is not going to skyrocket as the user's needs evolve.

[00:10:06]
So there are kind of two main pages we're gonna focus on here. One is the seed collection. So this is going to be solving kind of this problem here where we're incredibly disorganized. Like, how do we model one of these seed packets? What information goes on the back?

[00:10:24]
I'm going to play sort of your user here, and you're going to learn how to sort of tease information out of me so that you can identify, like, what are the most useful aspects of this to flesh out? Right. You could go in so many directions, but, like, part of what we're trying to learn here is, like, how do you get to the essence of what's most important?

[00:10:45]
Then the more involved part of this workshop, after we solve the seed collection in a basic way, we have waiting for us. A drag and drop user interface where you can grab these tiles, each of which represents a plant. And you can see carrots has this little down arrow.

[00:11:03]
There are many types of carrots here. You can drag them into the raised bed. And we're going to think about validation, logic, and how do we model the idea of putting a plant in a bed, moving it within a bed, moving it across beds. We'll talk a little bit later about transactionality.

[00:11:23]
Which of these operations should be atomic, meaning either all succeeds or all fails versus which ones? Is it okay that things are temporarily out of sync and will eventually converge on a consistent result?