Object-Oriented Design has been a powerful problem solving paradigm for many years now and it still continues to be a force, but as practiced traditionally it has also been limited in many ways. Any Architecture attempting to distribute objects across multiple nodes and processes while still trying to maintain object semantics soon encounters a scalability nightmare. The reasons for these limitations are a lack of constraints on object design around encapsulation and composition. Traditional Domain Driven Design builds on the principles of Object-Oriented Design and inherits some of these same limitations.

Traditional Object-Oriented Design principles work best when confined to the boundary of the local application context. Objects like String, Number, Lists, Maps, Trees and Graphics are represented well as fully encapsulated objects for consumption within a local application context. These objects are not meant to be distributed and scaled beyond one application process or even one user at a time in some cases. Scalability across many servers spanning many concurrent users requires a different design paradigm altogether.

Read the full article:
http://sonymathew.blogspot.com/2012/01/state-driven-design-sdd.html

Thanks much

Worst idea ever. You might as well implement a "doIt" method on the server side.

Han my man, if you read the article you'd know dolt() can be added to any service :-)

This article is waste of time, ultra-retro....

No, Closures and Functional Programming are ultra-retro. SDD is reality hitting you in the face.

The article is quite interesting. I am wondering if this is not some kind of Command Pattern? In this case, the state object, together with the operation name would give a command. From the caller point of view, each state object type corresponds to specific service:

• Account -> AccountService,
• AccountTransaction->AccountTransactionService,
• etc...

So, a command is {payload: anAccount, command: 'read'} or {payload: anAccountTransaction, command: 'create'}.

What do you think?

Perhaps my head can be twisted to see a command pattern.  A command such as AccountTransaction being processed by a sequence of AccountTransactionService objects.

simply a separation between data and services....needed in a multi-tier architecture so nothing new

You got it - its nothing new. Just trying to formalize something that is well-understood.

Worst idea ever! I see nothing but the big bad EJB 2 with a new name.

Using brain-less DTOs, using all the business logic in state-less services. No real domain modeling, even using some of "Core J2EE Patterns" such as "Composite View" (which was just created to minimize some of EJB 2 issues).

Beleive me, the Java community won't go back to claws of big bad dead EJB 2 era again, just renaming the beast!

Worst idea ever! I see nothing but the big bad EJB 2 with a new name.

Using brain-less DTOs, and having all the business logic in state-less services.

No real domain modeling, even using some of "Core J2EE Patterns" such as "Composite View" (which was just created to minimize some of EJB 2 issues).

Beleive me, the Java community won't go back to claws of big bad dead EJB 2 era again, just renaming the beast!

I didn't look deeply into the article, but the concept of state-driven architecture is one that is extremely natural in a distributed, highly-available scale-out architecture. In fact, it turns out that it is the only architecture that works reliably in such an environment, so I've been a proponent of the concept for years.

The specifics on this article may be good or bad, but please don't dismiss the concept of state-driven architecture.

Peace,

Cameron Purdy | Oracle

Cameron, you should read the specifics - its an attempt at formalizing your conclusion.

Amir, you might want to read up on EJB 2 and REST.

I’m not sure where you’re getting your info, but good topic. I needs to spend some time learning more or understand more. Thanks for fantastic info I was looking for this info for my mission. very broad for me. I am looking forward for your next post, I will try to get the hang of it!

___________________________

Newsletter Marketing

I agree with the content, but, Its just a pattern, I would not say a new paradigm or anything like that. We have been designing using this pattern for ever.

You got it - its nothing new. Just trying to formalize something that is well-understood.  But I disagree, it is indeed a paradigm shift from old-school OO.  I've also incorporated a pattern as you noticed.

Interesting, i replied to many comments here but only half of them show up at times while the other half shows up at other times...crazy.

TSS comments seem messed up, replied to several comments here but only some show up at any given time.

Mileta, Closures and Functional Programming are ultra-retro. SDD is reality hitting you in the face.

Witold, Perhaps my head can be twisted to see a command pattern.  A command such as AccountTransaction being processed by a sequence of AccountTransactionService objects.

Erik, You got it - its nothing new. Just trying to formalize something that is well-understood.

Amir, you might want to read up on EJB 2 and REST.

Cameron, hope you read the specifics - its an attempt at formalizing your conclusion.

Benjamine, thanks, hope I post something else :-)

Naresh, You got it - its nothing new. Just trying to formalize something that is well-understood.  But I disagree, it is indeed a paradigm shift from old-school OO.  I've also incorporated a pattern as you noticed.

Hello everyone, I'm a freelance writer. I love to watch horror movies. When not writing, I spend my time with friends, roaming in mall is our favorite pastime.