Are you using Object-Oriented Programming?

00:00:01 Dennis van der Stelt

Hello again everyone, and thanks for joining us for another particular live webinar. My name is Dennis van der Stelt, and today I'm joined by Vaughn Vernon. Vaughn is a prominent software engineer and author and expert in domain-driven design. He has authored influential books such as Implementing Domain-Driven Design and Domain-Driven Design Distilled, which provides practical guidance on applying DDD principles to real-world projects. Vaughn is also a sought after speaker and trainer, actively involved in the software community through conferences and workshops. And his work emphasizes on pragmatic approaches to software design, focusing on collaboration between tactical teams and domain experts to create scalable, maintainable systems that align with business needs. And today he's doing a webinar about if we are really using object-oriented programming.

Just a quick note before we begin, please use the Q&A feature to ask any questions you may have during today's webinar and we'll be sure to address them at the end of the presentation, depending on how much time there's left. We'll follow up offline to answer any questions we were unable to get to during the live webinar. And as a reminder, the webinar is being recorded and everyone will receive a link to the recording via email. All right, let's talk about object orientation, Vaughn Vernon, and welcome and thank you for being here.

00:01:31 Vaughn Vernon

Thank you, Dennis. Thanks to Particular Software for inviting me here. So welcome to my little presentation about object-oriented programming. Are you really using object-oriented programming? I would say that probably around the time that C++ was introduced, object-oriented programming wasn't very well known at all. In fact, I'm trying to think exactly when ... I think it was actually 1984, my wife and I had just gone on our honeymoon. We honeymooned in Rio, Brazil after our wedding and we got home and the week that we got home, I decided to take my wife on a really nice date. So we stopped in New York City to get a couple slices of pizza, and then we went to the C User Group in New York City. And the presentation that evening was about C++.

Well, I had just heard about C++ and I wanted to learn more, and I think I was one of five attendees. There weren't many people there. And I was kind of fascinated with the whole idea of object-oriented. I had been using C programming for about, maybe by that time, I don't know, a little more than a year, I think. I had done professionally just a little bit of basic programming, but that was a Skunk Works thing. And then I sold the C programming language. At a pretty young age, I sold it, the idea to our VP of systems, I think it was called at the time, that's kind of like a CIO today. And he was kind of a founder of the insurance-based company that I was working for.

So I sold him on C and we did pretty well with it. I have to say, we went from a piece of software that was written in Microsoft COBOL. I doubt that Microsoft still supports COBOL. I don't know if they've even supported in the past 20 years, but there was a Microsoft COBOL at one time, and the COBOL program was for entering hospital claims, insurance claims for hospitals so that the hospitals and the insured individual would get reimbursed more rapidly for any expenses that were incurred. So that was the whole differentiating proposition of this insurance, kind of like claims broker, I guess, you would say at the time.

And so the COBOL program was distributed on 10 diskettes, 10 floppy diskettes. There were 5.25 inch diskettes. And that was just the program file. So what you did is back in those days, if you were writing something in COBOL, for example, you used some kind of a chaining. You could do the same thing with basic at the time. So if you had a very large basic program, you could chain to another module, essentially just continue running the interpreter but on a different file. So you could do that and COBOL, you could sort of chain, I forget the exact language name, doesn't really matter at this point, but you could chain. And so what would happen is you'd get to a point in the program where you would have to use a different diskette, the program parts that were on a different diskette and it would say, "Remove disk drive number two from the A drive and then replace it with diskette number seven," for example, into the disk drive.

And there were just all kinds of problems because the IBM PC was fairly new. I think overall it was maybe introduced in 1981. By now, the PC had been around for ... By the time I started working on it in 1983, the PC had been around for a couple of years and hospitals didn't have ... I mean, if they had a computer, it was like an NCR or some kind of package program. Maybe really large hospitals would have, I don't know, mainframes. I don't really know what they used at the time, or maybe they did timeshare, which was kind of the thing back then. In fact, the larger insurance brokerage system ran in COBOL on Boeing computer services as in Boeing, the airplane, aircraft manufacturer, had a timeshare hosting with IBM mainframes. And the company that I worked for leased, whatever you called that at the time, but it was basically cloud.

So in 1983, we basically had cloud computing on Boeing computer services and everything was working with bi-synchronous communications, which was a blocking communication. But you could, I think what it was is you could send, with BISYNC, you could send messages in basically bytes in both directions at the same time, I think something like that. So maybe it was a little bit like TCP. Anyway, so that's what the environment was that I worked in at the time. And I saw this, I think it was very early in 1983 that Byte Magazine came out with this C programming language edition. It was all dedicated to the C programming language. And I was reading, reading, and I saw this and I went to the VP. I was like, "Bill, can we talk for a minute?" And Bill was like, "Yeah, sure." He called us wombats at the time, we were all wombats. He had worked at EDS, and he wore the whole three-piece suit with suspenders and bought his suits at Brooks Brothers like all the other executives in the building. And we were wombats. "Come on in Wombat, have a seat."

So I introduced Bill to, "Hey, Bill, I think if we were to use the C programming language, we could get the entire program on one diskette." And he was like, "No way." I don't know what he said. Something like, "No way wombat." And I thought, well, okay, that was a good try. And he was like, "So how much does it cost to get one of these things?" Very cost-conscious startup in Manhattan in New York City, Midtown, in fact, 3rd Avenue and 42nd Street, Northeast Corner. If you still know that area, you could still go to that building, that building right on the corner there. And I said, "Well, from what I can tell the best C compiler that I can find in this article, there were several listed." Microsoft had a C compiler, but it was actually the Lattice C Compiler. Lattice as in a lattice. There was a Lattice C Compiler, and Microsoft just rebranded it. So it was really the Lattice C Compiler. I think it may have shown copyright Microsoft instead of copyright Lattice, but it was the Lattice C Compiler.

There were a few other compilers, I don't remember the names, but they were all pretty pricey. And then there was this sort of strange little C compiler that cost about $100. The other ones were like $500 for the compiler. And I was pretty sure that Bill wasn't going to spend $500 on a chance that this might work. But also this little C compiler had a bunch of tools, it actually came with a program like a source code editor, which was not easy to come by at the time. I don't even remember what there was. There was eventually something called SPFPC, which was like the SPF mainframe editor, and someone mimicked the SPF IBM mainframe editor and made it work on the PC. And that's actually what I used when our program started getting really big, because the editor that we got with the C compiler couldn't handle really big files. And that tells you something about my programming skills at the time, I was pretty new to things.

So anyway, I talked Bill into buying this $109 compiler. It was like a sort of strange little ... Even the price of the product, still remember it was something like $109. And the name of that compiler was DeSmet, D-E-S-M-E-T. And if you're French or maybe, I don't know, I guess French, you're probably, "Oh, I know someone named DeSmet." I don't know if I even say it correctly, but that was the name of the compiler. And when you got tech support, you first talked to Joel. And strangely enough, I could swear that the guy's name was Joel Farley. I may be wrong about that, but I really think it was Joel Farley, interestingly enough.

And if Joel couldn't answer the question, then you got to talk to Mark Desmet, who was the author of the DeSmet C Compiler, and it was the fastest C compiler as in it compiled the fastest. They had their own linker, so you didn't have to use the Microsoft linker at the time for linking your object files into an EXE file. And they had the C editor, they had a few UNIX utilities as I recall, that came with the compiler. And the compiler produced the smallest object code of any of the compilers. So for example, it could be that the Microsoft C Compiler or Lattice at the time probably would've produced something like 250, 300 K EXE. And you're like, "Wow, that's really small." But that was kind of still big. It still would've taken two diskettes. There weren't any 512K diskettes at the time of, it was only 256K diskettes.

And in the end, we produced a 192K ... No, not 1902K, a 92K EXE. So under 100K. So about half to three times or one third the size of what the other C compilers were producing at the time. So it was pretty incredible. I was really happy. And we were basically done with the project as in the first stage of it was shipping at the time. By the time I went on my honeymoon, and I was like, "Wow, this is so cool. I don't have to think about this for a whole week." And it was crazy hours, I used to do and I still do. But I was like, "Okay, what's Next? And most programmers, especially young programmers, I was like, "Okay, I'm ready for the next challenge." And I go to the C++, essentially meetup, it was the C User Group, New York City C User Group. And there it was, C++. And I was like, wow, this seems pretty interesting.

But it was actually not until maybe a few years later, can't remember exactly, before I actually got a C++ compiler. And I learned a little trick back then. If you were a decent writer and you could write articles for trade journal magazines, paper magazines, they still had paper magazines. Well, that was the big thing back then. There was Dr. Dobb's Journal, there was Computer Language Journal, which was newer than Dr. Dobb's and some others, some UNIX journals and so forth. But if you could write an article for any of these journals, and it was about some programming language, the vendor would send you a free copy of the compiler or whatever. Well, I already had DeSmet C, and I think I somehow talked my wife into spending $500 for Microsoft C.

And by that time, Microsoft had taken their Xenix C Compiler that was Microsoft's BSD UNIX. And they owned this code. So they took their C compiler and ported it to DOS. And now Microsoft rivaled not quite as good as DeSmet C in size of the executable object code, but they were then producing some pretty tight code, a lot better than Lattice. So that was cool.And DeSmet started losing market share because of course, Microsoft's just going to squeeze them out. And DeSmet disappeared maybe by, I don't know, 1986 or something like that, is my guess. No one was paying attention to them anymore. And it was all about Microsoft C.

But in writing one of these articles, I said, "Well, I would like to write an article about C++." And so I proposed this to a journal. They didn't have much on C++ at the time. And so I pitched this and I got to write an article, and I got three different C++, they weren't even compilers at the time. They were called C-Front. It was a translator or a transpiler that would translate C++ code to C, and then you had to have a C compiler. Most of them only worked with Microsoft C, maybe Lattice C two. But that was a good thing that I had Microsoft C already. So the C-Front was what I actually got. And I wrote these articles. And so I got to learn C++ relatively early on. I mean, I think it was probably '85, '86, somewhere in there.

Okay, so this is my introduction to object-oriented programming. How do you think I felt later when the individual who invented, co-created Smalltalk Alan Kay said, "When I thought of the idea of object-oriented, I was not thinking of C++." So that was sort of this long-winded introduction to the zinger. It's like, wow, what did Alan Kay mean by that? Well, I'll tell you what Alan Kay meant by that, but let's step through a few ideas here first. So I hope everybody sees my screen. I've got these things covered up for the mystery of it all, and okay. And this is roughly what we think of as object-oriented programming. So we've got an instance of class A. So we could say this is actually A of A. And this is an instance B of B. And A has some reference to B, the object B, and it can do what? It can invoke methods on B. And you're like, yeah, okay, so what's new?

Well, when Alan Kay said, "When I thought of object-oriented or the idea of objects, I did not have C++ in mind." Alan Kay did not mean method invocations from one object to another. What did Alan Kay mean? Alan Kay meant this. That do something is actually a message that gets sent from A to B. And you're maybe like, "So what? What's the difference? What's the difference?" Well, I'll tell you what the difference is. No, let me have Alan Kay tell you what the difference is. Let me step you through a little history here of Smalltalk. So don't ... Yeah, ignore. Oh, no, wait, I was going to do this differently. I was going to do it like this so that I only reveal a little parts at a time. There you go.

Alan Kay is the creator of Smalltalk. And make no mistake about it, Alan Kay did not invent objects, but he did coin the name object-oriented programming. So he gets credit for that, and he should get a lot of credit for the Smalltalk language and his vision of what objects were supposed to be. He didn't invent objects. The objects came from a language which apparently was originally in Simula. Simula was a language used for simulation. And I think one of the simulations that the scientists were using at the time who used the Simula programming language was, believe it or not, like what would happen if there was an outbreak of a virus in an area that could spread very rapidly? What would be the impact?

Now, this was like in the late 1960s, about 1968. And if you want to frame that a little bit, this is also when Mel Conway, Melvin Conway finally got his paper published around 1968. In fact, in 1968, he got his paper published called How Committees Design. And this is where the Conway's Law, what really became famous out of that paper was stated in the conclusion of the paper. And it took him about a year to get that published because nobody thought it was important, and he finally got it published. And it wasn't until 1972. Now keep all these dates in mind because I think they're important. Just kind of put yourself in that era, this time when a lot of things, important things were starting to happen. Important things had already happened, but the shape of things was changing.

So 1968, Simula is there, it's available, scientists are using it to model simulations. Alan Kay sees Simula, and he gets ideas about objects and message passing. And by 1970, there was a very early version of the Smalltalk programming language, and it was roughly following the vision that Alan Kay had for Smalltalk. So '68, Mel Conway, Simula. Two years later, Alan Kay, Smalltalk initial version. Well, initially Smalltalk held to Kay's original vision of objects, but eventually Smalltalk parted from Kay's full vision, which disappointed him. In fact, he later said at some point, "I regret having even come up with the name objects or object," because he felt that the object itself had taken over the more important thing. And in fact, inside the object became the important thing. It all came down to like we perfect the inside of the object, but we're not that worried about the messaging between the objects, which really proved to be quite a downfall in my opinion. So objects weren't intended to focus on classes. Kay said the big idea is messaging. The big idea is messaging.

He also said at one point in trying to explain how to program with object-oriented, and he probably made a mistake in stating it like this, because he said, "Well, what you would do is you would implement a class and you would design a couple classes or implement a couple classes, and then you would send messages between classes." What stuck in everybody's mind or between objects, which were instances of those classes. And what seemed to stick in everybody's mind was the word classes. He wasn't trying to say classes were the important thing. He was saying, how you create objects is you first define a class and then you create or instantiate an object from the class. And the big idea is messaging. So that is really, truly honestly ... I mean, okay, should I admit how old ... No, I'm not going to tell you how old I was when all this was happening, but I was alive, but I wasn't old enough to appreciate this.

So I don't really know. I can't give you a history as if I was a little mouse sitting in the corner of Alan Kay's office, and I know all this stuff, but this is based on things that he has stated and been quoted on. And besides saying the big idea is messaging later on, he said, "Object-oriented programming or OOP to me means these things, these things, messaging." So he repeats that. "Messaging, local retention and protection and hiding of state process and extreme late binding of all things." Now, you got to cache that, especially ... What is extreme late binding of all things? Well, it simply means if I were to invoke a method on an object on get really early binding. The latest binding that I get is something like that one level of indirection where it says, okay, I've inherited, I've extended a parent, a superclass, and when I invoke a method, am I invoking the method on my class? Like if I am the object and I internally invoke a method on myself, am I invoking my method or am I invoking one of my parents' methods?

So that means that you need this kind of table that has a level of indirection that says, okay, let me look up what that is and we will then invoke that method over here. That's the latest binding. That is the very latest binding that you get in modern object-oriented programming languages. In Smalltalk and true object-oriented programming languages, it means that you could literally swap out the definition of a class at runtime or the definition of anything, and I'll get to that later, at runtime and completely replace it. Extreme late binding of all things. That means that you have to send messages because what will the current message that is in essence being sent to some object, in the classic sense, the real original sense of what Alan Kay meant about objects, you have to have a message that when it is sent, it first hits some level of, "What does this message mean? Oh, let me look that up."

And you can think of any kind of registry, any kind of dictionary. In fact, in the Smalltalk language, the thing that was used to dispatch messages to methods was a dictionary. And if you use C#, I think ... My memory, I've been using so many languages lately, but you have a dictionary type. Well, it's a hash table or a hash map. It's all the same thing. You have a key and a value, and I'm going to show you more about that, but that is important. Messaging and it's extreme late binding.

Now what about the other part? Local retention and protection and hiding of state hyphen process. So it means that you have state, it's protected, it's retained. So you have a state machine and it's hidden, the state is hidden, and the process itself is hidden. You can't touch the process without sending a message and having the extreme late binding bind the message to the current implementation. That's what it meant. And Kay also added, "It can be done with Smalltalk and Lisp. There are possibly other systems. Notice this. "Systems in which this is possible, but I'm not aware of them."

Now what did he mean by system? Well, if you've never used Smalltalk, and even if you have, it's worth recalling or learning that Smalltalk was this environment. In fact, when you kind of booted Smalltalk or you ran Smalltalk, you were kind of booting a machine. It was the Smalltalk virtual machine, and everything that belonged to that virtual machine was either in an image, what was called the Smalltalk image, or it was in a log file. Log file? You mean sort of like event sourcing? Yes, exactly. So for example, if I changed a method in my application or if I even went to a class at one of the system classes that was shipped with Smalltalk, I had all the source code, I could actually change those methods. Not like that was a great idea, but sometimes it was. And maybe I'll have time to tell you about that. And it's not for patching or monkey patching or anything. You could essentially patch any way you wanted to by extending the classes.

But anyway, kind of roughly forget that I said that. But let's say I'm changing a class, a method in a class that I have implemented for my application, what happens? I hit control S to save. That is both compiled and if it compiles properly, is persisted to a log file. It was a log file. You could, if you messed up in implementing a method or changing a method, let's say changing a method.

So you change the method and you can now go back to your log and it's called the change log. You could go back to the log and you could open that file. You don't want to touch anything in the Smalltalk environment while you're doing this, but you could take that file, open it, and you could go back and select the previous ... You could find the previous implementation of that, or you could simply delete the implementation that you just messed up on from the log file, save it, and then refile in, re-cache that change log file and the changes that you just made disappear. Or you want to go down three versions, grab this and bring it in.

Okay, I have not talked to Kent Beck, I have never talked to Kent Beck, talked. I think we've maybe exchanged a few ideas, but if you go to some recent ideas from Kent Beck, and he says, "Literally every change that I make in my source code, I want it in Git. I want it." And you might look at that and go like, that's crazy. But that's actually what he's ... I mean, I don't know that that's what he's drawing from, but in my viewpoint, when I read something where he says that I'm going, he's thinking Smalltalk and the change log. Well, Smalltalk had some problems in that the environment was really great for single developers, but you didn't really have a way to share code other than filing out your classes into some kind of log and then some other developer filing them into their image. And you can imagine that very quickly, things can become crazy.

And one of the reasons that I did patch Smalltalk, the actual shipped classes, and I think I only had to patch three different classes, was I created essentially a version control system for Smalltalk for our team because there was nothing. So in fact, we could just save various versions of classes, and every time that you changed one of your classes, it got a new version and you could then save any number of those, every one, because they're still in the changelog. And you could file those out, well file them out a source code repository, and then another developer could say, "Oh, look, Vaughn recently made some changes." Well, you didn't look at those files like raw like you had to basically with the changelog.

In fact, there was an idea back then called a changelog browser, and you could go and because Smalltalk gave you all the tools to deal with its own language, with classes, with everything, with the log file, you could simply go and create ... You just bring up a new browser, which looked like the other Smalltalk source code browsers, but it was browsing the changelog. And you could just click one of the classes and one of the methods that's in the Changelog, and say, "I want to file that in," instead of having to go into that, essentially a text file and do all of the tweaking yourself.

This is the thing that is crazy incredible about Smalltalk. And if you know anyone who's ever developed in Smalltalk, I don't know. There are a lot of bitter old Smalltalkers because the language just went away. It wasn't practical anymore that the problems that you had to solve, like the change problem between teams was an issue, but it was pretty incredible. And I think you can now see the local retention, messaging and at least late binding, but nobody out on the outside got to see the state, you didn't have a way to go and manipulate the state of some object directly. You had to send a message to it, and if you wanted to get some state about it, you had to send a message to it. And the binding for that could be set dynamically. It could be set dynamically.

In fact, as you were developing, if you wanted to add a class to the source code control system, I would insert a method into that class, an instance method, or maybe it was a class method, not like static at all, but yeah, that idea right on the class side, and that kept the version. So every time that class changed, it kept the version of what had changed within there. So you could patch the source code at runtime, and you might think, "Wow, that's really dangerous." Well, it's only dangerous if you're not protecting it.

So anyway, what is all this leading to? Alan Kay said at one point in an interview with Dr. Dobb's, "What do you think of the actor model?" Was the question. And Alan Kay said, "The actor model retained more of what I thought were the good features of the object idea," meaning message passing between actors. The actors are basically objects, and this message passing occurs between them. And if you ever heard Carl Hewitt talk about actors, and sadly he died, I think it was in 2002, very young, at 77 years of age. It's very sad. Carl Hewitt was the inventor of the actor model along with I guess some colleagues at MIT at the time, they were working in the AI lab. Wow. A little bit before their time. And when? 1972.

So Alan Kay goes, or someone, I think it was Alan Kay goes to MIT and presents this to Carl Hewitt, and Carl Hewitt sees it, and he says, "Well, you know what?" Whatever. Do you call each other doctor when you're both doctors? "Well, Dr. Kay," or does he say, "Hey, Alan, what you're doing here, yeah, it's kind of messaging, but it's not really messaging because it's not asynchronous." And Alan Kay says, "Huh, tell me more." Well, in a year, there was the first actor model-based programming language implemented by Carl Hewitt and others at MIT, and it looked a lot like Smalltalk, but it worked asynchronously. So now you get the idea because the actor model is all about sending messages.

And then the last part of this, later on, Alan Kay told a early story of Smalltalk, which you can find online. And in there he said, "The actor's work as in the work of Carl Hewitt, remained more true to the original object ideas than our Smalltalk work at Park remained." It started out what Kay was thinking, but as always, more people get involved and ideas change, and the class became more important and things just did not go in the direction that its inventor had. He went along with it, I don't remember how long he stayed with Park, but he still was at Park when Smalltalk 80 was introduced. But now you see that little pocket of time, '68, '70, '72, '73. Pretty important timeframe.

But what in the world is this whole messaging deal? Well, the messaging deal is this. Yeah. Alan Kay in one of his talks said, "To understand what I mean about objects and the importance of messaging is I have to use the Japanese word, 'Ma'. The Japanese word 'Ma' means not this. The space between. It just means the space between. And there is no English word, single word that he was aware of or that I'm aware, like I matter at all. But the point is he just said to get the idea of what I mean about the importance of messaging is the important thing about object-oriented is the messaging. It's the space between objects, between objects, meaning that if you have an instance of A and an instance of B, the space between is right here. It is the message that you are sending from A to B. That is what the space between means, the 'Ma', meaning and what Alan Kay was all ...

I think he even said this, you can go look up the space between 'Ma'. I haven't watched this talk recently. Maybe I should have, but I haven't had time. But I think he also says that it's like, "Okay, we get obsessed with everything inside the object." What I think about that is, and I mean no disrespect, but okay, you get the idea. This is what we're interested in. Solid. And I have to say that is not what Alan Kay meant when he was talking about objects. We're perfecting the inside of things. We give so much attention to that. And what is the protocol between these? Oh, my word, getters and setters. It's just property, public properties, public whatever, getters, setters, you name it.

So I described this a little bit earlier. When you send a message from an A to a B, what happens in Smalltalk? Well, you go down to this table, which is basically an instance of a dictionary that is named, I don't remember, I'm sorry, but it's probably something like instance methods. And you look up this key, which do something is actually called a message selector. It is the name of the object. So while you're programming ... The dot isn't there in smalltalk, so you would be sending message, do something to B, there is no dot there, and Smalltalk understands that you are sending this parameter list message, do something to an object named B. The compiler takes that and it says, "I'm going to turn that string into what's called a symbol." And the symbol is simply a string, an immutable string that has this kind of pound sign at the front of it. You create other symbols, use symbols for things like configuration or whatever, your key value pair type things. You don't have to, but it was a good idea.

So you look this up in the instance methods dictionary, and you go, "Oh, that means there's a method on B, and it's an instance method on B. and I can now invoke the method." Invoke is something that happened late because Smalltalk supported extreme late binding of all things. Extreme late binding of all things. So if I wanted to at runtime, I could go replace what do something does at runtime, no problem at all. Again, it's only dangerous if it's not secure. And you might say, "Well, that's always." And I'm thinking, yeah, but same thing could happen in JavaScript quite easily on a browser. Tell me it couldn't, even with obfuscation.

So what is this leading to? Well, in reality, what Carl Hewitt was saying is, "Okay, this is kind of message sending, but what I have in mind is asynchronous message sending, which is really, really message sending." So you even have more of an opportunity to distribute this. Wait a minute, aren't we just talking about running inside of VM? Yeah, well, absolutely right, but this is what we have even whether we're talking about C++, Java, C#, F#, whatever. This is basically what we have when we invoke a method, we have an active passive state, A, the A is active until it invokes a method on the B. Oops. I keep doing that. And when it does, the A becomes passive and the B becomes active, and there might be an exception thrown. And that looks weird because it just ... Boom, there it is. It just ends up rewinding the stack, and there it is.

In C, that was called longjmp, longjmp. L-O-N-G-J-M-P, not J-U-M-P, because symbol names could only be seven characters long when C was first designed. This is what Carl Hewitt had in mind. Active-active. B is always available. It just isn't doing anything unless it's handling a message. The A is always available too. And even after it handles a message and sends a message, it's not blocking. It's still available. While B, this B is handling the do something message delivery in its invoked method that was invoked by the delivery of the message, the A is ready to do something else while that's happening. So that's the active-active state. That's what Karl Hewitt had in mind.

Now one in the world is A and B anyway? A is anything, B is anything, and the supervisor, which is part of ... Well, I don't actually know if Karl Hewitt had supervision in the early actor model, but that showed up with Erlang, which actually had nothing to do with the actor model. That idea of Erlang came completely independently, and it was only afterwards that they were like, "Oh, it's true." Academia and industry both create the same things separately. And some people will argue that Erlang and Elixir and basically the BEAM virtual machine is not really supporting the actor model. I don't really care. It's fundamentally the actor model. And I think it would adhere to Carl Hewitt's idea of the actor model, but I don't know if I've even heard him say that.

Okay, so what am I driving at here? It could be anything. So you mean that an A could be a rest client and a B could be a rest server? Yeah, exactly. That's exactly what I mean. So you send a post message. It is a message. If you go look at the HTTP protocol, assuming that you're using rest over HTTP, the HTTP protocol ... What time is it? Oh, I'm almost out time, I guess, but okay, I'll get there soon. I talk too much. But I like sharing history. It's pretty important, at least what I know about it.

So you send a post message, go look at the HTTP spec. Every single thing, post, put, get, patch, delete, da, da, da, they're all messages. The post message. You'll read message there. It's all messaging. Now you're thinking, yeah, but it's blocking messaging. Well, that doesn't have to be true either. I've implemented async HTTP clients, designed them, I've implemented async HTTP services or server like the receiver, basically the client side. Well, this is actually a client too. It's just a different kind of client. It's a client of looking at what's being received, but in essence, it's a channel connection. So you can do that. But besides that, after you post, and I hope I get this right, because I often forget which number it is. I don't know why, but I do. But instead of sending back a 201, you send back a 202, which is accepted, and that basically says, "Got it, got your post message" or got whatever message it is that you sent. I'm acknowledging that I received it, but I don't know what the answer is yet. And so I'm not going to tell you.

But in this protocol between the A and the B, you have to have as part of the protocol, how will B eventually send the answer back? And what that will be is after some time, there's going to be another post message to some URL that was supplied by the A and yeah, yeah, yeah. All the security stuff. I'm not downplaying it, but I have to move on here. So it can be anything. Oh, really? So you're saying that an A as an object, could send an event to a database? Yep, that's exactly what I mean. And do you mean that a database or the database object? I could draw this as a circle to make it look more like what I like to use as representing actors. But you get the idea. Could the database object after the bytes are actually on disk, could it actually send that event to end NServiceBus? Yes, it could. And could end NServiceBus send that event to a saga? Yes, it could. And could the saga send through end NServiceBus a command to the B? Yes, it could.

And what I want you to take away from this today, so yeah ... Actually I had to figure out what to do with my time because I was like, I don't have too many sort of slides here, so what am I going to do? Well, this is my message. If you're using particular softwares and NServiceBus, you are more object-oriented than if you are using C# and F# or whatever alone. So that's my message. I think I'm ending one minute early, but I'm available for questions if you want, and if it's not too late, if Dennis and the gang still want to continue. So that's all I've got. I guess there's some Q&A. Chat is disabled. Ruby has this feature.

Some questions came in over email.

Okay.

There was one very interesting, or as a Dutch person, I could relate to it a little bit. I don't know if you know the answer, but the question is, "In an object-oriented farm with an object-oriented cow and object-oriented milk, does the object-oriented milk send an unmilk message to the object-oriented cow, or does the object-oriented cow send the de-cow message to the object-oriented milk?

Excellent question. Excellent question. So it reminds me of a book. So there was the Bjarne Stroustrup book on C++, just like there was the K&R book, the Kernighan and Ritchie book on C, Bjarne Stroustrup wrote the C++ book. And then right after that, soon after, well, soon, I don't know, soon after that, in 1980s soon, there was another book called ... Was it C++ perimeter or something? I don't remember. But it was about the same size as one of those narrow books. And that book used a really real world example, and that was a toaster and bread. And the example was like, okay, I send a message to the toaster that says toast, and the bread goes down into the toaster and the toaster times it, or whatever it was, understands when the bread is at the right darkness, toastiness, and then pops the toast up. That was sort of like the whole use case throughout the book.

I didn't know much at the time, but I rolled my eyes at that, and other people rolled their eyes at it too, and they were like, "This is the worst book ever." But you know what? It's not an entirely bad question for today, because what you would have, you wouldn't actually have a cow and you wouldn't actually have the milk and the farm and more cows and more milk that are actually digital. But what you could have is a digital twin of all of those things. So you could put a meter, and if you want to know how much milk is being milked from every cow, well, you could know that. And after a certain amount of milk, maybe there is a pressure gauge on the automatic milker. So on big farms that do this kind of thing, that this would even be applicable at all, there are machines.

And I don't know, maybe you already know that you could actually go to a farm in the Netherlands, and they're making a lot of cheese there. So they're milking a lot of cows. And I'm kind of certain that you could probably find an automatic milking mechanism that has this kind of built-in feature that says, "Oh, I can sense that the pressure of the amount of milk coming out of the cow udders right now." You think I don't know about cows. I know cows. that the pressure of the amount of milk coming out of the cow says, "Stop. Cow's done." And of course, you have a digital twin for the monitor of the milker thingy, the mechanism that attaches to the udders of the cow, and that sends a message to the whatever, and that sends a message to the whatever. And yes. So actually, maybe this was a bit of a troll, but this is actually maybe what they're doing right now with NServiceBus, whoever asked that, I don't know.

So yep, you could do that. What is this? Well, this is an IOT device. And this is, yeah, some okay database, but it's the digital twin that actually receives it here. So maybe NServiceBus, I don't know. Maybe end NServiceBus is here in the middle. I don't know if NServiceBus supports MQTT, but is that right, MQTT? Anyway, I'm not right up on my IOT stuff. It's not cashed in my brain right now. If NServiceBus supported MQTT, it could do that. So yeah, it could be that, but the device here has to be ... Well, it could use actually as much power as it wants because it's hooked up to the automatic milking and there's electricity there, so it's not like you're worried about low power situations, battery and recharging and all that stuff. So yep, you could do that. So kind of like silly question, but not silly question in our day and age. Is that okay?

Yeah, for sure. We are already six minutes over time, so we'll end it here.

Okay.

For the listeners and viewers, be aware that Vaughn also has workshops and that you can attend. Some of us at Particular Software will also be speaking among others at .NET Switzerland, Techorama and NDC Porto. And if you're interested in the concepts that Vaughn Vernon presented in this webinar or where all of this stuff is coming from, we heard a lot of history from him. Udi Dahan is doing his advanced distributed system design course in London later this year, and more information about the events we're at can be seen at particular.net/events. That's all we have time for today. On behalf of Vaughn Vernon, this is Dennis van der Stelt saying goodbye for now and see you on the next Particular live webinar. Thanks for attending.

Are you using Object-Oriented Programming?

🔗Why attend?

🔗In this webinar you’ll learn:

🔗Transcription

About Vaughn Vernon

Additional resources