Depending on what our system is supposed to achieve, it can be important to save events. In the case of our doorbell example where I am in the shower, we might have the problem that I can not hear the event as well as my decision to not respond to it. Depending on the reason the person triggering the event had, this can either be acceptable or not.
If it were the postman trying to drop off a package and they don't want to wait, they can have a short timeout to await a response and if they don't get one, they can queue the package delivery again on their side, get back in the van, and try again tomorrow. In other circumstances when we want the system delivering the event to handle this scenario for us, this is also common, for example, when I miss a call, I will get an SMS with the call details, or a voicemail saving the event details for me and when I'm ready to handle it I can do so.
In many software systems, we want the event delivery system to abstract away as many things as possible. Going all the way to the extreme, it is even possible to construct the system purely by storing the events and never actually modifying any data, but just generating new events to again be stored. All the system needs to know at this point is at which point in time a consumer is in regards to the event stream, and it can then replay whatever is needed, obviating the need to store modifiable data by mapping entities to a database. The only entity in this scenario is the pointer into the event log for each consumer. This is not something that is easy to implement as it raises problems due to the only eventually consistent nature of such a system.
After all, it takes time to send events between systems, but it might be worth it for a reasonably complex system to tackle.
A very good example of such a system is Kafka, and it is a whole
ecosystem for modeling, consuming, event creation, and storage, but there are other examples for this as well. Martin Kleppman has written about, and presented on this, at various occasions, for example, at Spanconf 2014:
https://www.youtube.com/watch?v=b_H4FFE3wP0.
Creating a system like this is probably not the simplest or the first choice when
developing a business application as the requirements for the infrastructure to support it are quite high. The more the application has to deal with high availability and the more the system starts to be distributed for whatever reason, the more reasonable such a system becomes. JavaScript as a language is very well suited to event handling, as it is at the core of the domain the language was build for—reacting to user events in the browser.
Further reading
Throughout this chapter, there have been a lot of things introduced that are not the primary focus but still added a great deal of understanding to the evolvement of domain-driven design. Being inspired by workarounds can really improve the general software development practices so there is further reading I would recommend. To further understand object orientation, and especially to find design patterns to use, I recommend the book called Gang of four, and Design Patterns : Elements of Reusable Object-Oriented Software, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Pearson Publishing. Even though the book is old, it still represents classic work on object orientation, and establishes a lot of terminology.
Also Smalltalk Best Practice Patterns, Kent Becks, Prentice Hall, really embraces Object-Oriented design, and even though both books are naturally not focused on JavaScript, they can still be very helpful in advancing your design skills.
At the other end of the chapter, we went into some detail on how to get started on modeling a flow of events, which is currently a very hot topic. Martin Kleppmann has been doing a lot of work around this area, so following his work closely will bring you some good insights into how to model growing applications (https://martin.
kleppmann.com/).
There is obviously a lot more to follow up on, but getting started with the mentioned work will naturally lead to a lot more, probably more than is digestible in a short amount of time, so I recommend you go and follow this up and follow it down the rabbit hole.
Summary
In this chapter, we looked at the various ways domain-driven design is influenced and can be augmented by related software development patterns. Some patterns are closer than others, such as DSLs, and some are more orthogonal such as modeling the system as a series of events.
The important thing is to make sure we don't get stuck in trying to only apply the techniques we see in a specific pattern, but look at what is around to make sure we use the right tool for the job. At its core, domain-driven design is about modeling business software, and while most business software follows similar patterns and rules, some internal details might be very well-suited for a functional core integrated in the software as a whole, or even the development of a DSL that allows not-so-technical business experts to express their rules clearly.
In the next chapter, we are going to sum up all the details we came across and are going to think about how to work on an ever-changing product like most business