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 teams?
Yes, reactive still matters and XOOM is still relevant. Here I have enumerated some basic reasons for this.
Reactive—There are few frameworks or toolkits that broadly support reactive software development. Being reactive means that your component A is not blocking a computer processor’s use for a response from component B from which an action or data was requested. With XOOM every single component is built on a reactive, non-blocking runtime using the Actor Model. Read about the Actor Model here. Reactive and message-driven is an effective way to develop software because it makes efficient use of all computer processors and performs and scales much better than non-reactive software.
Domain-Driven Design—Other frameworks/toolkits get in the way of DDD by insisting that the strong opinions of its creators be adopted and followed. These opinions are locked into the APIs and the documentation, tutorials, and training of these frameworks/toolkits, which promote an implicit and anemic form of programming. One of the major opinions forced onto developers is to favor a data model rather than a domain model. Another big problem is that those who promote data models over domain models actually label the result as a “domain model.” This is not only misleading but wrong. By design XOOM both promotes and supports fluent domain modeling with expressiveness. The XOOM API is itself fluent and thus encourages model fluency along with the components that support the fluent (true) business-centric domain model. In combination with a fluent domain model design, developers can create code that is readable by other developers and even business people. This means that intention is explicit and clear by the language of the software in a context.
Message Driven and Event Driven—Other frameworks/toolkits have at best added some event-driven capabilities as an afterthought, and don’t support message-driven at their foundation. With XOOM a message-driven runtime is available at its core, and by definition support the Actor Model means that everything in the platform, as well as all microservice business components, are message-driven. We support event-driven components as first-class concepts, including Event Sourcing and CQRS.
