BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Reactive Messaging Patterns with the Actor Model Book Review and Q&A with Vaughn Vernon

Reactive Messaging Patterns with the Actor Model Book Review and Q&A with Vaughn Vernon

Enterprise software development is hard, Vaughn Vernon claims in the start of his new book Reactive Messaging Patterns with the Actor Model from Addison-Wesley. He emphasizes that his statement is not specifically about multithreading or concurrency, instead a general statement he believes to be true. The reason enterprise software development is hard are all the frameworks, patterns, software layers, messaging systems, application servers and databases needed. Vernon refers to the Ports and Adapters (a.k.a. Hexagonal) architecture described in his earlier book Implementing Domain-Driven Design where he explains why it simplifies an enterprise solution. He notes though that even for senior architects and developers it takes months to comprehend such an architecture. Thinking about all the things involved and the accidental complexity at play he calls this the complexity stack.

In contrast, what we are really trying to achieve in an application is to submit commands expressing the user’s intent to a domain model and to store the domain events created as a result of the commands. This is a simple and powerful model that Vernon calls the simplicity stack, which also brings him to the subject of his book, the Actor model, which he introduces in the first chapter together with the tenets of reactive software.

Vernon uses Scala and Akka in his examples and in chapter 2 he provides a simple tutorial on Scala basics as a preparation for the code examples later in the book. In the same chapter he also provides a detailed introduction to Akka as well as the basics of supervision, remoting, clustering and testing of actors.

In Chapter 3 Vernon looks into performance and how it has increased during the last decades into today’s 64-bit, large cache, multi-core processors. He believes that the Actor model is an important approach for accomplishing performance and scalability in the enterprise and that actors can help mitigate multithreading complexities and leverage the use of these modern multi-core processors.

The main part, Chapters 4 – 10, of Vernon’s book is a patterns catalogue describing most of the patterns in the bookEnterprise Integration Patterns by Gregor Hohpe and Bobby Woolf but from an Actor model perspective. These chapters cover among other things the foundational messaging patterns, basic channel mechanisms, and message construction, routing and transformations. To simplify both making and understanding actor model diagrams, Vernon has collaborated with Typesafe to create a set of standard actor model elements. Code examples for the book are avilable for download.

In an interview with InfoQ Vernon shared his views about Actor model, Domain-Driven Design, Microservices and CQRS.

InfoQ: Who are the intended readers and what can they expect to learn?

Vaughn Vernon: My purpose in writing the book was to provide software developers at all levels with introductory and advanced guidance in how they can create the next generation of software that is not only concurrent, parallel, scalable, and performance capable, but also resilient, with low latency and high throughput. It teaches how to create software that is both multi-threaded and message-driven through and through, and that teams can actually reason about. I think of the book as a whole as a loud shout out that the Actor model with Akka is a relatively simple way to achieve concurrency, parallelism, at scale, with resiliency, in the everyday IT enterprise. In its individual patterns, it shows in detail how the building blocks can be used to lead teams to such advanced applications and systems. To put it in a way that most enterprise architects and developers will appreciate, it is the way to do SOA right.

InfoQ: Since your last book was about DDD, can you tell us about your journey from DDD over to Actor model?

Vernon: From my viewpoint it is not a matter of shifting away from DDD to Actor model, but embracing both together. I think that the Actor model is a natural way to implement DDD in the contemporary enterprise, and this is a point that I strive to emphasize in this new book. I actually discuss DDD at appropriate points throughout the text and I heavily reference my IDDD book at times when I think the reader can benefit from more depth on various DDD topics. One of the DDD themes that I stress is that DDD is about being explicit about the business domain, and that Actor model with Akka is one of the best ways to express a domain model with explicitness and without unnecessary architectural overhead and accidental (or intended!) complexity. For me the journey was short and sweet, and I found the Actor model to be a perfect companion for DDD in practice.

InfoQ: How close are the original object orientation ideas by Alan Kay and the Actor model?

Vernon: According to Alan Kay, the Actor model retained most of the important aspects of how he intended object-oriented to work. He has stated that message sending between objects was a much more important focus than how objects are internally implemented. Well, that's basically the Actor model. I get the impression that if Alan Kay had had the opportunity to follow his vision to the full, the Smalltalk language and environment would have eventually become actors throughout. That would have been a compelling platform, and one that I think would have endured the test of several decades. I loved Smalltalk development as it was. I can only imagine what a Smalltalk-actor environment would have done for programming. But, I suppose when Smalltalk was at its peak in the early to mid-1990s, we still didn't have affordable/pervasive hardware to really make that possible. As it stands today, Scala and Akka form a highly productive environment to achieving much the same thing, and especially because Scala is both object-oriented and supports even more functional programming concepts than Smalltalk. It's an incredibly productive environment and one that reminds me a lot of the old days with Smalltalk, which was a pure object-oriented programming language and development platform.

InfoQ: What is the relation between CQRS, including event sourcing, and Actor model?

Vernon: Actors make perfect DDD Aggregates because they are atomic processing units that form the ideal transactional boundary. So that's a big perk for using Actor model with DDD, at least from a tactical approach. Another essential point is that Actor model being message-driven means that actors fit naturally into an event-driven architecture. With event-driven, actors can easily support Event Sourcing, where the Events Messages produced by an actor are used to produce their persistent state. However, you can't really query an Event Journal very practically unless you project the events into a query model. So, when you use Event Sourcing it means that you need to use CQRS so you can query data that was produced as the result of sending actors Command Messages. It all works together quite well, and as Akka matures the support for Event Sourcing and CQRS has become more and more advanced. Today you can choose from tools such as Akka Persistence, Akka Query, which are part of the Akka project, and a newer tool named Eventuate. Eventuate shows a lot of promise and in a few ways is more advanced than Akka Persistence and Akka Query. I am currently using Eventuate on a Scala-Akka project, and I am quite pleased with it. Either way, you will be served quite well using either of these tool sets.

InfoQ: How big is an actor from a DDD – Aggregate, or a microservice perspective?

Vernon: Like I suggested earlier, an actor makes a perfect DDD Aggregate. I really don't like to answer questions about Actor model and microservices only because microservices have many conceptual definitions. Still, I will attempt to provide an answer based on my own experience. I think that sometimes a microservice will be quite small, because it will tend to provide just a few features, which you might think of as service endpoints. (You might also think of a microservice providing just a few kinds of REST resources through a limited number of URI patterns.) In such a case, you would still probably have a dozen or fewer actor types in this level of microservice, because there are several things that it needs to support. We were just discussing CQRS, and in my experience you will have actors to support the following: One Aggregate type, one Process Manager, View projectors (actors that react to new events to keep the Query Model up-to-date), and Query services. This doesn't even consider how service/resource controllers will be supported. For even a very focused microservice this results in perhaps 6-10 actor types, and perhaps millions of actor instances implementing individual Aggregates as domain objects.

On the other hand, I think that sometimes a microservice is closer to a DDD Bounded Context. I will add here that what I just previously described as a very focused microservice probably doesn't describe an entire Bounded Context--it probably just supports a limited part of a larger logical Bounded Context. But, I have also created microservices that are larger than this and are really a full Bounded Context, where you have perhaps 5-10 Aggregate types. Even so, the microservice is in no way a monolith because there are probably a total of 20-25 actor types that support Aggregates, Process Managers, View projectors, and Query services.

InfoQ: Do you think that the Actor model will be mainstream for developers someday?

Vernon:  I sure hope so, because if it does not then it means that developers everywhere have not learned that they must move on from the former enterprise server technologies that cannot scale and perform as will be necessary over the next few decades. I will add that I think that Akka is becoming mainstream, as can be seen in the number of support Q&A forum posts there are on the Akka user group. There are constantly developers new to Akka asking basic questions, which shows a lot of uptake, and obviously a great audience for my new book. Microsoft has also contributed to the available Actor model tools with Project Orleans, and there is also Akka.NET that is available for the .NET platform. I will also add that Akka Typed is an upcoming project that makes designing typed actors possible (as Microsoft's Orleans provides) and may make adopting Akka even more attractive to those that are strong-typing proponents.

About the Book Author

Vaughn Vernon is a thought leader in simplifying software design and implementation and the author of the two books Implementing Domain-Driven Design and Reactive Messaging Patterns with the Actor Model. He has been programming with object-oriented languages since the 1980s and applying the tenets of Domain-Driven Design since his Smalltalk domain modelling days in the early 1990s. Vernon is interested in distributed computing, messaging, and in particular the Actor model. Since a few years he has specialized in applying the Actor model with Domain-Driven Design.

Rate this Article

Adoption
Style

BT