Client-Server Domain Separation

http://byterot.blogspot.com/2012/11/client-server-domain-separation-csds-rest.html

by aliostad • 14 years ago

22 13 14 years ago

byterot.blogspot.com

PaulHoule2• 14 years ago

mediocre systems are encapsulated; great systems are codesigned.

secoif2• 14 years ago

Co-design is unrelated to encapsulation.

PaulHoule2• 14 years ago

There's encapsulation as an engineering practice and then encapsulation as a religion.

This balls-to-the-walls approach to SOA is one of the shortest and straightest roads to software development hell. I've seen appaling amounts of money disappear in failing projects this way. (Ever wonder what happened at Colours? I used to, until I found out...)

In this wonderland of things being decoupled you find pretty quickly that a lot of functionality gets duplicated in multiple layers, and whenever that functionality is at all subtle, you'll find that every implementation is wrong with different bugs.

A while back I worked with some guy who was into REST and HATEOS and PhD thesises about as valid as Carlos Castenada's and the result was his team spent a year and a half building an app that took 20,000 REST calls and 40 minutes to start. In a week of whole-system thinking I was able to get that down to one POX call and 20 seconds.

He never forgave me.

If you're in one of those organizations that uses scrum as a substitute for project management, failure is even more assured with SOA. Because then, when a whole-system problem needs to be solved, everything has to be synchronized against the phony deadlines imposed by the process so something that could be done in 6 days ends up taking 6 weeks.

SOA gives people the illusion they're managing complexity so now they can throw a 20 person team at a job a 4 person team could do. The 20 person team might get the job done 10% more quickly than the 4 person team, but it's five times as productive at creating bugs. The 4 person team is more "agile" because it spends resources on satisfying business needs rather than creating levels of encapsulation just to have encaspulation, then discovering at the last minute they put walls in the wrong places and need to take out the Sawzall (if they don't hand out the pink slips)

The ultimate way to fight complexity is to fight it directly, that is, don't create it. Every artifact you create is like a puppy you'll need to take care of. Every address space you cross is another thing that can screw up, so don't do it because "it's the thing to do", do it because there is a real gain that overcomes the very real cost.

DenisM3• 14 years ago

On the other hands, mediocre systems often times win in the market due to their greater predictability. Working with isolated system is iterative, if inefficient, but working with integrated system requires deep insight which is not always available.

lucian303• 14 years ago

Please explain as the sentence makes no sense. The two things have nothing to do with each other.

ivix• 14 years ago

Surely this is the only sane way to design a REST API? Of course taken to extremes, things can get silly.

As I see it, the point of encapsulation is that you don't know what your system might be asked to do next. Keeping things reasonably generic allows you to respond without a major redesign being required.

hizanberg• 14 years ago

Keeping the client and server separate is a new thing? Isn't that what most of the world is doing already?

Since the purpose of a service is to provide a service, why would you be limiting it to specific clients in the first place?

csense• 14 years ago

As of this writing, this article is only a couple spots away from the front page. It's clearly not front page material, though.

Separating a large, complicated task into multiple orthogonal pieces, and assigning each of these pieces to its own component, has been a fundamental part of software engineering for many decades.

Separation of concerns is what OO does. Separation of concerns is what UNIX does. Separation of concerns is what TCP/IP does. Separation of concerns is why global variables are considered "bad." Separation of concerns is not a new idea.

This jargon-filled, somewhat poorly worded article is merely repeating a fundamental principle that should be obvious to anyone who's ever written any program larger than a couple hundred lines.

What is meant by "[the] client is free to have full coherence of server's public domain including all its public API, domain objects and schemata"?

"CSDS regards hypermedia an important aspect of REST; it is a semantic web of interconnected resources. Client will have full coherence of the axes of such relationships and can effectively use to navigate the semantic web - since it is part of the public domain. But for it to become the engine of the application is server dominance." These sentences are a long string of big words, but I'm not sure that there's actually anything meaningful in them.

Reading this article makes me really wish I had enough karma to downvote.

aliostad2• 14 years ago

I am really happy if you think all of this is common sense. In fact a lot of software best practices are common sense but they do not necessarily consistent with each other. Even in life, "Always help others" and "Set your goals and run for them" are common sense but they will make a different person out of you. There comes a time when you are at a fork and need to make a decision and then it is down to which one is really what you believe in.

Decision to separate domains of client and server is a big one and has its implications. CSDS is common sense as is HATEOAS but they are not consistent. ROCA is also common sense but does not agree with CSDS.

Client-Server Domain Separation

Related Stories