2005 all over again - domain driven design, where are we?

[Nik]

Thanks for the reply.

I don't think that this could be answered for a general case, but it looks ok to me as you've done it.

It doesn't look that nice when the adding method takes a string (a Product would make the association more clear) but I think that would result in code leaking out into the calling action. And if there would be more code in the callee, it should be moved somewhere (a service?), but in both cases logic is moved away from the domain object...

I wouldn't expect an addXXX method to take a row number argument. In any case, if it is not domain relevant I would omit it.

I lost you there. The add method doesn't take an argument but the order is the only one to know the row number of the next row (relevant in ordering the rows).

In my opinion yes. Persistence operations should not be placed inside model objects themselves. That should be handled by repositories. Besides that: When using ORM you can achieve to save dependent objects together with their root object by appropriate mapping declarations.

Yep. Although sometimes the ORMs can be a pain in the neck when you have some contraint on the table that is violated becase the ORM decides to do updates and deletes in certain order etc.

P.S.: I recommend "POJOs in Action" by Chris Richardson which covers these aspects quite well.

Yep, its on my (slowly advancing) reading list...

P.P.S.: I would refrain from using a service locator as you do in your code as it is more difficult to test. An alternative is passing in the needed objects as parameters.

Could you elaborate? I usually find it handy just to inject a common root locator so you can have access to any service without rewiring.

[Andreas Senft]

It doesn't look that nice when the adding method takes a string (a Product would make the association more clear) but I think that would result in code leaking out into the calling action. And if there would be more code in the callee, it should be moved somewhere (a service?), but in both cases logic is moved away from the domain object...

As I said, no general solution...

I lost you there. The add method doesn't take an argument but the order is the only one to know the row number of the next row (relevant in ordering the rows).

That was my point. I interpreted your question that you thought about adding a row number to the signature.

Could you elaborate? I usually find it handy just to inject a common root locator so you can have access to any service without rewiring.

If you want to test a method that uses a locator (usually a static method) then your test inevitable tests the locator functionality as well. You cannot test in isolation which is especially uncomfortable when this requires infrastructure as database access or the like.
When you pass in your repository (or what else) you are able to mock that dependency in your test, enabling you to have isolated test cases.
This is also elaborated on in the book I mentioned.

Regards,
Andreas

[craig.schneider]

I am still trying to wrap my head around the benefits of DDD. The main concern I have - my domain objects are directly accessed by the view layer (JSPs). By implementing business logic on our domain objects, are we not creating a security risk by possibly exposing sensitive methods to the client?

[Nik]

I am still trying to wrap my head around the benefits of DDD. The main concern I have - my domain objects are directly accessed by the view layer (JSPs). By implementing business logic on our domain objects, are we not creating a security risk by possibly exposing sensitive methods to the client?

Well, it's not like the users can do XSS and execute arbitrary methods on the objects. Or?

[lloyd.mcclendon]

I am not sure i follow this, what exactly is this trying to solve? It seems to me like it is rebelling against current trends just for the sake of being different, not really making it easier to deliver quality software faster. Hell nobody here really even knows how to do it, which tells me it is a probably a suspect concept. If it did make sense we should have lots of well known examples and be using it by now. But I hope I am missing something.

What exactly is wrong with the anemic domain model? Seriously I'd like someone to answer that one because it really hasn't been addressed here yet. Isn't having the logic to

addOrderRow() throws 18BillionExceptions {
useLotsOfDependencies();
}

outside of the model in a service better seperation? And how is "repository" different from "business service" which both use 1 DAO and N services to provide a higher level interface? Same thing different name...

Instead of the controller calling the service, it calls the model, which calls the service (er repository .. if thats what you want to call it to feel better about it). Where is the benefit of that?

I've always thought of the domain objects as books on a shelf, when I need to manipulate a set of books I ask the librarian, yelling at the books doesn't do much. Now you are saying the books should have eyes and ears, so I talk to them and they talk to the librarian for me. I hope I am misunderstanding because that just sounds like foolishly reshuffling everything for no reason.

But I am with you on the modify a domain property -> break view page thing, that sucks. And I don't even see how that would solve this. Your view will still reference _some_ object, and eclipse won't detect changes to it no matter what useless layer you decide to put it in.

[gmatthews]

which tells me it is a probably a suspect concept

I agree. I call "shennanigans" on domain driven design.

[Andreas Senft]

What exactly is wrong with the anemic domain model?

Well, in my opinion an anaemic domain model is not really following the OO paradigm. An object has to contain data and operations on that data (i.e. behavior). And getters/setters do not really count as behavior.

I think it has been the advent of EJB which forced using anaemic domain models as EJBs poorly addressed fundamental OO concepts as hierarchy and polymorphism. Besides that, the proposition of entity beans prevented efficient augmentation with behaviour, so putting everything in services instead.
As this model became ubiquitous for quite a while, the "real" OO approach has been forgotten and is now resurfacing within the DDD movement.

And the benefit? The idea of tying data and behaviour together is to provide cohesion which facilitates understanding of the code and it also improves maintainability.

Just my 2 cents,
Andreas

[gmatthews]

Well, in my opinion an anaemic domain model is not really following the OO paradigm. An object has to contain data and operations on that data (i.e. behavior). And getters/setters do not really count as behavior.

DDD is nonsense because as soon as you introduce the idea that an object behaves differently depending on its context the idea of bunging every single possible method into it becomes stupid.

DDD might work for a bunch of little objects which:
- aren't used across VMs
- aren't used in messaging
- don't care about performance
- etc.

Data just simply isn't suited to OO treatment, otherwise like above, if it was meant to be it would have been done by now.

I'd be looking for a completely new approach to make DDD work -- trying to shoehorn it into OO isn't going to work, not while there are networks, messaging queues, databases, and application performance, etc. to deal with.

[Andreas Senft]

DDD is nonsense because as soon as you introduce the idea that an object behaves differently depending on its context the idea of bunging every single possible method into it becomes stupid.

I never suggested to put "every single possible method" into an object. And which context are you referring to? Do you mean by context where an object is being used (server, client, ...)? I think by applying sensible design rules there shouldn't be that big problems. I suggest to have a read to the DDD book by Eric Evans and "POJOs in Action" by Chris Richardson. That might make things a bit clearer.

Data just simply isn't suited to OO treatment, otherwise like above, if it was meant to be it would have been done by now.

So I take it you are suggesting to return to the procedural programming paradigm again?

I'd be looking for a completely new approach to make DDD work -- trying to shoehorn it into OO isn't going to work

DDD has OO as its foundation (as also stated in the books mentioned above), so I daresay it would be difficult to use it without that. But if you can come up with a new approach feel free to share it here. It is always beneficial to evaluate different viewpoints.

Regards,
Andreas

[gmatthews]

I've read the book

So I take it you are suggesting to return to the procedural programming paradigm again?

Sometimes OO, sometimes procedural -- but not everything will be in the style of Object->Operation();

A toolkit called Voyager, which existed maybe 7-8 years ago had a novel approach where you could acquire an interface to some aspect of the object.

e.g.

invoiceObj.persistenceOf().save();

This seemed to acknowledge that object lives in different spaces (e.g. client/server like you mentioned) and that sometimes an aspect wasn't available.

e.g. .persistenceOf() might return null.

I'd be more accepting of DDD theory if it provided examples based on more complex system architectures than 3 or 4 objects running in a single VM.

I think the only way forward out of DDD nonsense land is for someone to specify a non-trivial system with multiple VMs, databases, queues, web + rich client and then for someone to implement what they consider to be a DDD solution.

i.e. show me some real non-trivial solution instead of waffling and flailing about.


----

follow up..

----

As a follow up, what I don't get is "what's the point of DDD" -- my code is already mostly OO, its readable, its maintainable, it works pretty fast, so why bother going to extra mile?

I'm actually more interested in getting my hands on the Spring OSGi implementation and seeing how that impacts software architecture rather than taking DDD to the n'th degree.