First look - REST architecture

After working with the REST architecture for over a year now, it's about time to mention some of it's traits. I started with reading the book REST in Practice and of course the very famous How I explained REST to My Wife. Must confess that this was the first architecture which appeared simple and straight-forward. Couldn't wait to put REST into practice.

During the course of the last year, I've been involved in designing several RESTful services. Having to stick to the standard HTTP protocol and verbs makes life much simpler when trying to figure out how the services should look like. There's not much room for creativity there! That said, all the creativity lies in getting the resources right. I must have spend 80% of the time in modeling the resources and attaching them to the respective domains. Used Domain Driven Design principles to modeling. This process of design helps create and document domain models, which were always missing and now without whom life seems impossible.

Some best practices to building RESTful services:

• Domain model design preceeds service design
• Stick to the standard HTTP protocol
• Establish patterns specific to the applications, and write them down as guidelines
• Create a service catalog for the RESTful services

Overall, I've been very satisfied with the REST architecture. When implemented cautiously, it has the ability to create a services landscape, which are re-usable across front ends, and other systems. A dream of many, a reality for some!

Do we developers care about the business domain we work on?

Do we developers care about the business domain we’re working on? Or should we developers care about the business domain we’re working on? Domain knowledge for a developer is mostly a nice to have (and not a must have) entity. Sure, a developer with absolutely no knowledge about the domain can write good quality code incorporating all the patterns and best practices that are.  But can he/she produce a high-quality product? By product I mean here a ‘system’ or an ‘application’.

What happens when a developer tries to understand a business domain? Lot of knowledge transfer sessions take place between him/her and the functional guys/gals. Such a session typically includes lot of talk or lot of presentations flying around. After many of such meets, a developer begins to grasp the mechanics and dynamics of the domain. Super! He/She feels better equipped and motivated to do the task at hand. With that high-note, he/she begins reading the functional specs of the first use cases defined for the system. And most often to his/her utter disappointment, he/she realizes that not only are the specs ‘not complete’, but also wouldn’t fit together to make a 'complete system’. What happens then are more discussions where he/she tries to convince the functional specifiers of his/her findings. And before they all know it, the project is already running late resulting in enormous pressure on development to deliver working software. So was the whole need to understand the domain worth it!

The reason why this situation arises over and over again is due to the utterly bad tooling our functional specifiers use. Although these are the guys/gals who really understand and envision the system, they have no feedback on whether their specifications are complete and whether they end up in working software. More agile methodologies to software development have made this feedback cycle shorter, but it still exists. Wouldn’t it be nice for functional specifiers to have the tooling which validates their work? A tooling which guides them to a complete, working system. Some of you must have already guessed it. Yes, I’m talking about DSLs (Domain Specific Langauges) or DDD (Domain Driven Development) here. Languages which understand the domain and help specify it. This would remove that extra overhead and feedback loop.

Does this mean that the developers would be out of jobs? No, only now their time will be spent in developing these DSLs. This gives an opportunity to everyone to excel in their own discipline – the functional specifiers in the business domain and the developers in development. And also results in software which is tightly coupled to its specifications. A win-win-win I would say!