Comments on: Services in Domain-Driven Design

By: Which services are considered Infrastructure Services | Code and Programming

Mon, 31 Dec 2012 16:24:58 +0000

[...] From: [...]

By: Tom Rossen

Tom Rossen — Fri, 03 Aug 2012 20:31:00 +0000

“Infrastructure” is a misleading term from a legacy worldview very different from DDD. The only “infrastructure” under the domain layer is the language and the machine – the CLR/JVM/whatever.

By: CQRS & DDD – Domain Model Business Rules validation using cqrs read model | PHP Developer Resource

Tue, 29 May 2012 05:16:06 +0000

[...] Implement Domain Services as Extension Methods for the repository, Jimmy Bogard has a definition http://lostechies.com/jimmybogard/2008/08/21/services-in-domain-driven-design/ Tagged: CQRSdomain-driven-designquestions /* * * CONFIGURATION VARIABLES: EDIT BEFORE [...]

By: Naming Your Services « Rockstar Engineering

Naming Your Services « Rockstar Engineering — Wed, 16 May 2012 00:49:27 +0000

[...] the end of the day, I take my cue from this blog post which has some wonderful advice for naming your services. I am quoting its advice here: Domain services are the coordinators, allowing higher level [...]

By: Jeune Asuncion

Jeune Asuncion — Wed, 18 Apr 2012 03:23:00 +0000

Thanks for this post. It cleared up some things on my mind. I had the dilemma of how I would name my service and the post helped me make things clear.

What did you mean by application services? Is this just your term for API like the one exposed by Twitter et.al?

By: Jimmy Bogard

Jimmy Bogard — Tue, 20 Mar 2012 13:16:00 +0000

That makes sense – although I don’t know why my code would need to pass through an interface layer. Why have a layer of indirection?

For external clients that makes sense, although I would want to be careful not to fall into the trap of exposing capabilities through an RPC endpoint.

By: Jimmy Bogard

Jimmy Bogard — Tue, 20 Mar 2012 13:15:00 +0000

I don’t think Infrastructure is the core layer – the domain layer is.

By: Your fan

Your fan — Tue, 20 Mar 2012 09:37:00 +0000

Jimmy, a novice question, in your article you tell that application layer are those rom which outside world contacts, but when i was viewing ddd sample of eric evans , he specified one more layer, ie Interface layer, so all calls from my code behind pass through interface layer and then into application service layer. One more point if i want to write a wcf service so that, java guys can also consume my application functionalities how will i do that in ddd ?

By: Anonymous

Anonymous — Tue, 15 Nov 2011 19:28:00 +0000

If someone is down in the weeds interacting directly with a domain object, but can’t supply what the dependency should be, why should this be pushed down to the ORM?

Putting it another way – would you want the domain object interacting with a static helper class instead of an injected dependency, how is that any different?

By: Kelly Brownsberger

Kelly Brownsberger — Tue, 15 Nov 2011 18:11:00 +0000

Yeah… I remember that post and I tend to share your point of view. However, I can also see the other point of view where now callers who may not know or care what the implementation of the balance calculator is must know and care. While this approach is intention revealing in the sense that callers know something non-trivial is going to happen and something other than the current internal state of the domain object is needed, what if they don’t want to know? I understand from a testing perspective have a blackbox behind each domain behavior can become a nightmare to test in isolation, but at the same time exposing these things to the caller can make their job more difficult too. Callers now have to know how to construct them or go get them from somewhere (like a container). I’m not sure that’s better.

I’m just trying to dissect the pros and cons from all angles. I can think of 3 or 4 ways to approach this, but none of them are without their respective cons. Service injection seems like it could get out of hand and kill the simplicity of new’ing up POCO. Do you have any links to horror stories of this approach? Sounded like you have a long list of pitfalls in mind with this. Would appreciate hearing any lessons you’ve learned there

Cheers