I consider myself a refugee from the old JEE architectures. Threading was handled (naively, for the most part) by the container. Requests were synchronous, transactions distributed. The applications were deployed to a private data center, so scaling the ponderous beast was handled by scaling out (nodes to a weblogic cluster) and scaling up (increasing memory
We love our handpicked trainers! Here is an opportunity for you to get to know Tomasz Jaskula, our trainer for French and Polish IDDD Workshops. Tomasz Jaskula Tomasz, you’ve known Vaughn for many years. How did you meet? I had the pleasure of meeting Vaughn in person in 2013 during one of the first IDDD
I had the pleasure of meeting a wonderful group of individuals in Amsterdam who participated in the Reactive Domain-Driven Design with the XOOM/PLATFORM day. Wow! That’s a mouthfull! Some of the XOOM contributors and the Kalele team were able to carve out some time in everyone’s busy schedule to connect in the wonderful city of
The easiest way to get up and running quickly with XOOM, along with an explanation of our position on open source innovation. We’ve decided to introduce a familiar way to learn the different components of the XOOM toolset—without the need to understand everything about our platform up front. It is our belief that all application
The inquiry arrived: “Are time lapsed events Domain Events?” The question is the result of wrestling with whether YearEnded and similar occurrences are actually useful. The inquirer’s assertion is that rather than capturing the fact that the year ended, just send a Command that requires some outcome as a result of the fact that the year ended. Of
I was asked to justify reactive software development and XOOM for teams that have already achieved development and deployment of microservices. Here’s the question: After your team has reached the point of developing microservices, perhaps even successfully strangling a Big Ball of Mud monolith, does reactive still matter, and does XOOM still have relevance to such
I have been using various forms of messaging for more than 30 years. Messaging has become second nature to me, but I empathize when others say that messaging is to them unfamiliar and intimidating. Since the Actor Model is based on message passing, it stands to reason that this programming model is likewise unfamiliar and
Tonight after midnight in Barcelona, I was in a conversation about CQRS and how using Domain Events or not using them can impact the Command Model and the projection of changes into the Query Model. This led to some interesting points raised regarding the intent of Domain Events and some basic “rules” on how they
I recently read an article about Cloud-Native vs Reactive development, in which the statement is made that Cloud-Native looks a lot like Reactive. The article asserts several points that could make pursuit of both Cloud-Native and Reactive seem unreachably complex.
With the continuous news about the XOOM/PLATFORM you’ve probably been wondering how you can put the reactive goodness to use. Here I explain how the use XOOM/ACTORS to achieve asynchronous messaging between objects, which are implemented as actors.
Several have requested a document describing the XOOM/PLATFORM architecture. So here it is. This specific article is kept relatively brief. This is in part to emphasize the simplicity of the XOOM/PLATFORM. It’s just not complicated or difficult to describe. The other motivation for brevity is not knowing entirely what architects and developers are looking for in
This new platform represents my vision for software development from years ago. I have taken a few side tracks along the way. Previously I felt that I would be better off trying to contribute my vision to heavily funded efforts that have multiple teams, those that would easily out perform me alone. That was a
