The Reactive Manifesto
Join the DZone community and get the full member experience.Join For Free
over the past couple of months i have been helping out some friends to update the reactive manifesto .
there are several reasons why i agreed to help. first i was asked to, by my old friend martin thompson . the most important reason though is because i think that this is an important idea.
the reactive manifesto starts from a simple thought. 21st century problems are not well-served by 20th century assumptions of software architecture. the game is moving on!
there are lots of reasons for this: the problems that we are asked to tackle are growing in scale, sometimes in complexity too; the demands of our users are changing; the hardware environment has, and continues to change. the rate of change in our best businesses is increasing.
talk to any of my friends and they will, no doubt, tell you that i am a bore on the topic of software design – as well as several other subjects
i think that we, as an industry, don’t spend enough time thinking about the design of our solutions. too often we start out projects by saying “i have my language installed, my web-server, i have spring, hibernate, ruby-on-rails, <insert your favourite framework here> and my database ready to go – now, what is the problem?”. we have become lazy and look for cookie-cutter solutions. we then proceed to write code in straight-lines – poor abstraction, little modelling, rotten separation of concerns. where is the fun in any of that?
i get genuine pleasure from creating solutions to problems, but i don’t get pleasure from just any old solution. code that only does the job is not enough for me. i want to do the job with as few instructions as possible, as little duplication. i want the systems that i write to be efficient, readable, testable, flexible, easy to maintain, high-quality, dare i say elegant!
i have been lucky enough to work on a few systems that looked like this. do you know what? when we achieve those things we are also more efficient and more cost-effective as developers. the software that we create is more efficient too, it runs faster, does more with fewer instructions and is more flexible. this not over-engineering, this is professionalism.
interestingly their are sometimes similarities in the course-grained architecture of such systems, at least on the larger ones that i have worked on. they are loose-coupled, based on services that implement specific bounded-contexts within the problem domain, that communicate with each other only via asynchronous messaging. these systems almost never look like the standard, out-of-the-box three-layer architecture built on top of a relational database, although pieces of them may use some of the standard technologies, including rdbms.
the hardware environment in which our software executes is changing. the difference in the cost per byte between ram and disk is reducing. the capacity of ram is increasing dramatically. distributed programming is the norm now, the relative performance of some of our hardware infrastructure has changed (e.g. network is now faster than disk). large-scale non-volatile ram is on the horizon. all this means that the assumptions that underpinned the ‘standard-approach’ have changed. the old assumptions don’t match either the hardware environment nor the problems that we are solving.
the reactive manifesto is about discarding some of those assumptions. about more effectively modelling the problems in our problem domain, writing code that is easier to test, more efficient to run, easier to distribute and that is dramatically more flexible in use.
take a look at the reactive manifesto . if you think we are right please sign it, more than 8000 other people have done so so far. if you think we are wrong, tell us where.
most importantly of all, please don’t assume that the same old way of doing things is the best approach to every problem.
Published at DZone with permission of Dave Farley, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.