That kind of behavior can be built using the Active Record pattern instead of the Domain Model pattern. As you said, it is simple data manipulation and, as such, doesn’t require it. That said, DDD is broader than the Domain Model pattern and there are many other useful elements to it that can still be applicable.

Sorry to bother you again, i have read Eric Evan’s book (maybe i should read it again) but I seem to struggle with what would appear in the domain side of things, everything seems to be a service/crud based method of the system. The examples given always seem to fit nicely with business logic (I think I may be interpreting my own system incorrectly) Would you mind suggesting a couple of typical domain methods for the following :

If i have an estate and this contains regions in the country and these contain houses, the user can add new regions to the estate and houses to regions and view the houses details.

Does this sound like something that warrents DDD or am I trying to fit something in that just doesnt fit, I cant believe this, as nearly all web based systems are just reflections over data at their core and merely provide facilities for the users to perform basic crud methods on a system. Would you model the crud methods e.g. AddRegion as a domain method or just at the service level?

Sorry to be a pain, but this is one of the biggest hurdles I always have with DDD, if you can suggest any reading or articles, I would be extremely grateful (where did I put Erics book…)

I think that the issue is that the UI you’re supporting is exposing that kind of functionality to the user. DDD applies to UI design as well.

The code in the post is indeed the implementation of service layer methods.

good post, always like reading your work but have a question, The original example (makes use of the session) looks more like a Unit of work service method than a traditional DDD method, is there anything wrong with the code you posted being placed in the service layer which makes use of the domain model? the reason I ask is I am struggling when thinking in domain methods as most of the domain methods i think of really just model crud behaviour. For example, I am working on some software right now where you basically have an estate which can have a number of sites and all I seem to be modelling is Estate.AddSite, Estate.RemoveSite etc. And the only thing I seem to be putting in my domain object is validation e.g. the Site description cannot be blank…

Would you class these as domain methods or just service layer methods?
I think you’re right in terms of this takes a whole different mind set !

The service layer is inherently integration code and, as such, most suitable for integration testing (rather than unit testing).

The advantage of services talking directly to ISession is simplicity, and the ability to use the power of the framework chosen (NHibernate).

But if you are using directly, it seem that your services is taking repository function and how do you test it? What is the advantage to have services direct query/get data from dataaccess framework (for example NHibernate)

Thanks

I’m not sure what you mean by exposing ISession, but service layer code does make use of ISession directly, yes.

Glad you liked it.

Yes, I could have done that kind of constructor for Appointment. However, in terms of DDD, I don’t see there being an appointment that could exist without an ICandidate. I also worry about “generic” Accept methods as they may guide people to thinking about the visitor pattern when that’s not what is occuring.

I’m not sure I’m so much “taking advantage of the features of the ORM” so much as designing a persistent ignorant domain model.

On the issue of fluent interfaces – it just looks like I did something special. Actually,

interviewer.ScheduleInterviewWith(candidate)

returns an IAppointmentThatHasNotBeenScheduled which has a method:

At(DateTime time);

So, while I don’t explicitly go looking for how to use fluent interfaces in the domain model, the fact that I use intention revealing interfaces often leads to something that looks fluent. But usually, there is none of the chaining behavior found so often when doing the fluent thing.

Hope that makes sense.

Appointment appointment = new Appointment(message.RequestedTime, a.Candidate);
interviewer.AddAppointment(appointment);

Also whilst I like the example you provide I’d also be happy with the service layer calling methods on the Appointment directly such as appointment.Accept() rather than calling ICandidate.Accept(appointment).

I also think theres really two points you are making here. One is that you think its good to take advantage of the features of the ORM so that when you save an interviewer its appointments are saved, the other is the fluent interface example.

I’m also interested, do you use fluent interfaces a lot in the domain? So far I’ve only found them useful for simple value objects and entities, particularly creation.

It looks like there will be a lot more systems to rewrite in the future with the growing popularity of RoR, doesn’t it?

I think CRUDs spoil the application, putting business logic in the user behaviour, instead that in the application. But the process of bringing the business logic back into the app is not always straightforward: you need to have smart people to interact with, different skills and motivation and probably some extra time.
Sometimes this is worth the effort, but some other times a quick collection of CRUDs, maybe implemented fast with Ruby on Rails or Grails is all you need, especially for small applications.

Alberto

Thanks for the answer – I might go and track down some of the earlier posts – always an interesting discussion

Nick

Session.Save is not called in “interviewer.ScheduleInterviewWith(candidate).At(message.RequestedTime);”

The domain objects have no persistence code in them whatsoever.

The O/R Mapper needs to be configured in such a way so that persistence occurs by virtue of the fact that there is an unsaved appointment object in the interviewer’s collection of appointments.

Does that make sense?

I’ve been seeing that question pop up multiple times on the DDD threads and have just stopped answering it there

The Domain Model is a self-contained component – it doesn’t take dependencies on anything else. What it does is raise events that external code can use to make decisions about which external “service” to call.

Does that make sense?

In the “traditional O/R mapping solution”, we have:

using (ISession session = SessionFactory.OpenSession())
using (ITransaction tx = session.BeginTransaction())
{
…
session.Save(a);
…
}

In the “domain-driven” solution, I assume session.Save is called inside:

interviewer.ScheduleInterviewWith(candidate).At(message.RequestedTime);

So, how do you have access to the session object here, as its not explicitly passed? Is session effectively an alias to a singleton then (does OpenSession return an existing open session if there is one)? Is this typical when using ORM?

How do you handle the limitations that you hit when your domain objects need services in order to fulfil their responsibilities? Do you inject dependencies, pass dependencies through with method calls or keep your domain model self-contained and access external services from the calling code?

Of course the interviewer object will be creating an appointment object and adding it to its list. The thing is that that’s encapsulated. If it were to add other objects as well, you wouldn’t see that either.

You can see that by working entirely in memory that way in the domain model we can more easily unit test those business rules.

The service layer doesn’t have to explicitly INSERT those objects in the DB. CRUD usually refers to the act of actually working against the DB interfaces – creating an object in memory and connecting it to (and with) other objects is rarely viewed as CRUD.

Does that make sense?

interviewer.ScheduleInterviewWith(candidate).At(message.RequestedTime);
tx.Commit();

Takes a candidate assigns him to interviewer with a time slot.

Now a level deep, interviewer.ScheduleInterviewWith is certainly going to perform CRUD (CREATE READ UPDATE And Delete over some memory space).
Isn’t it like CRUD with wrappers.