In what way does it make you feel dirty? The 2 diagrams show 2 different things....the first one shows a possible technical implementation while the latter looks at it from a concerns/services/domain perspective.

Looks like a standard SOA setup to me. Whack an interoperable XML+HTTP interface in-front of each service and you're good to go.

I've been developing in this way for years (and ServiceStack is really tuned for this) of easily building multiple autonomous services. This architecture involves a little mind shift, i.e. instead of developing a service for your smart client, you develop re-usable services for your business which your smart client happen to use.

I believe that people are using this approach with the old vision of 3 tiers.

Many people want to have an application server to put all logic inside (rules, domain models, services, etc.). If you notice, "business logic" is just a wrapper to the Data Access. So, any operation that will be executed, they will pay the overhead of distributed communication.

I implement my software like second image, and I put some functionality in the application server if really needs.

Don't you see the client as a composite of those things as well?

These two diagrams are not mutually exclusive, since they represent two different things...

Maybe you can show the second diagram and say something like "ok, let's take 'catalog' as example and work on the implementation. It will be an application server with WCF and NHibernate" and you put the first diagram there.

I agree with some other comments that these two diagrams represent two different things. Although there are cases when application is implemented as 1, and it should have been 2. Or vice versa.

But perhaps you can give some more specific examples?

One other thing. Don't you see a bigger danger for spaghetti code in (2)? People can bend a definition of a smart client and end up in a real mess. While (1) leaves more room for maintainable design.

Surely one is management and the other is for the enlightened ;)

Ayende

Can you please elaborate a bit more? Especially "I really don’t like or believe in building applications in this manner anymore"

I've had the misfortune of being a spectator to the destruction of an MVC application built using NH, Castle & Rhino Commons.

It already had distinct logical services that operated on the same domain objects which were later converted to WCF, DTO, and buses that took you nowhere.

Is your context just that of smart/rich clients?

If so is the second scenario exposing say distinct (WCF) services that handle specific areas of functionality?

By the way, even the latest rich client panacea from Microsoft (RIA services) seems to be hung up on enabling CRUD & change tracking!

Ajai

Are you breaking up the second diagram between the "smart client" and the services that the client needs? I'm assuming that you're going to back to a discussion a while back in which you advocated presenting a service layer to any clients that need access to the data store.

If you can find the time, I'd like to read more of your thoughts on this as well because I get the impression I'm missing something.

So you want your smart client to be a smarter client. But what about business logic as it relates to multiple clients accessing the same model ? That logic really needs to reside on an app server.

As Paul mentioned, I would also be cautious to put too much orchestration logic in the (too) smart client ...

Isnt this about the same as DDD bounded contexts?

It's like layers/tiers and modules. This can be seen e. g. in WCSF.