The demands for software projects increase rapidly as time progresses. So does the scope of architecture approaches to meet these needs. This section will give you an overview of the concepts and implementations Spine has inherited, while bringing some important differences into play.
Spine didn’t appear out of the blue. While working on our own CQRS/ES based projects we were alarmed at how much manual effort is spent on creating events and commands, delivering events and data to the web and mobile clients. It takes time, does not require much creativity from a developer, whilst this energy could have been spent on productive Event Storming, detailing the Domain model and so on. Attempts to address this issue led to the Spine vision.
A major addition Spine brings to the existent variety of tools, libraries, and frameworks is automatic code generation for multiple application clients. It is reached by using Protocol Buffers.
When creating an Event Sourcing application, you need to write classes for commands, events, command handlers, aggregates, aggregate repositories, DTOs etc. And if your organization wants an application on, let’s say, a couple of mobile platforms, you would have to add a lot of work to deliver data to each client application. So you need to make your code work on another platform by writing it in another language manually, or translate it using tools like J2ObjC, or resort to using only Json in the client apps.
Immutability is another major concept we follow. Spine uses typed commands and events. Having commands and events as first class citizens in the applications gives a lot of benefits in terms of business logic. Not having to convert back and forth with Json gives some performance advantage at the same time.
In Spine Event Engine we combined all of our experience and observations of the best-breed market products and solutions like Axon, Spring, Event Store, InfluxDB, Apache Zest and many others. Spine has yet to find its own niche.
Spine probably won’t be the best fit for trading or highly loaded applications, where, for example, LMAX does an excellent job. Our motivation is to make development of modern applications easier and more efficient, and to offer a set of practical solutions to bring this into life with a corresponding approach and terminology.
We learned a lot from the book “CQRS Journey” by Microsoft, and our choice of the term “Process Manager” over the commonly used “Saga” is based on the experience of Microsoft engineers. The “Process Manager” pattern was first defined and brought into common vocabulary by Kyle Brown and Bobby Woolf under the guidance of Martin Fowler in the book “Enterprise Integration Patterns”.
Another great resource on object-oriented design worth mentioning here is “Patterns of Enterprise Application Architecture” by Martin Fowler. Many modern frameworks implement these patterns behind the scenes, and so does Spine. But as Martin Fowler notes:
Frameworks still require you to make decisions about how to use them, and knowing the underlying patterns is essential if you are to make wise choices.
Systems built on top of Spine framework are flexible, loosely-coupled, scalable and open to change. Here we should thank Reactive Manifesto, which became one the corner stones and drivers of the Spine philosophy.
We are yet at the beginning of our journey of using Spine in the wild. Join us and share how it goes!