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

[sbtourist]

Regarding your observations on repositories and DAOs, what is the level of granularity of repositories that u suggest ? I mean, DAOs usually have one implementation per database table, what about repositories ?

Repositories have a different granularity than DAOs: there's usually one repository per aggregate root, because root entities are the only one with independent lifecycle, while other entities should be "saved" and "retrieved" through their relative root entities.

In case I want to inject data access services within my domain object, should I inject repositories or DAOs ? I have been injecting DAOs with fairly good result - what is ur take on this ?

I usually inject repositories, because:
1 - Their interface is expressed in terms of domain entities.
2 - They usually implement business behaviour that must happen when making CRUD operations.

However, repositories and DAOs can be implemented as the same object, i.e. using the Separated Interface pattern: so, what's your way of implementing repositories and/or DAOs?

Cheers,

Sergio B.

[sbtourist]

And using the domain model in the view layer never gave me a good feeling. It works - yes it does, they both do - and in simple examples it looks really easy and natural to use domain models in your view layer. But when things begin to get complicated I prefer using DTO's, they are clean, simple and contain exactly what is needed.

I've also worked at projects with both approaches: maintaing DTOs was a pain, while directly using domain objects was much cleaner.
However, this is my experience, and you can obviously disagree

It's not clean to keep the complete session open

Why do you say that?

Haven't used Wicket so can't elaborate on that one, but for the moment I'm very satisfied with GWT.
[CUT]
In high level my app looks like
[CUT]
This is also the very first time I'm giving an object oriented DB a try, Hibernate is cool but I think sometimes used in cases where it should better not have been used. We need to realize that RDBMS is not the only choice out there, using an OODMS relieves us from ORM hell :-) Or at least I hope it was a good decision... time will tell :-$
[CUT]

Regarding Wicket and GWT : it is true that they "easily" let you code complex UIs, but they have IMHO a great flaw : they make separation of concerns useless, forcing developers to produce a lot of Java code.
Regarding OODBMS vs RDBMS : your experiment sounds exciting: let us know how things go!

So ... it would be great if you could just post some small code snippets introducing us on how you are applying DDD

I'll surely post something in my blog, as soon as I'll have more time and energy.
I'll let you know.

In the meantime, let us go on with this discussion.

Cheers!

Sergio B.

[manifoldronin]

I agree, it is not directly related to DDD, but I think it is one of the most used 'hacks' out there. It's not clean to keep the complete session open - but that my opinion, and many agree and many disagree... :-)
But it would be nice to have some examples that show us how to use hibernate objects in JSP's with lazy loading but without the OSIVFilter.

Well, we need to be careful with the distinction between "session" and "transaction" here. It's not clean to keep a business transaction open for view rendering purpose, but there is nothing wrong with keeping a hibernate session open until all the DB activities serving the same request are completed.

[manifoldronin]

I must say, I have been doing J2EE development for 5 years now, I have used domain models directly in the view layer (jsp, velocity, ...) and I have also used DTO's. And using the domain model in the view layer never gave me a good feeling. It works - yes it does, they both do - and in simple examples it looks really easy and natural to use domain models in your view layer. But when things begin to get complicated I prefer using DTO's, they are clean, simple and contain exactly what is needed. Let me give an example:

- You need to show a search result page, a table with multiple rows and multiple columns
-Too fill the columns of each result row data needs to be retrieved from multiple domain objects which are not associated with each other (no direct link)
- Beside that other trivial (non domain object data) needs to be shown in columns, i.e. some calculated data or so...
- Pushing all that information to a JSP or so really feels ugly, because in this case you still need a wrapper class that holds all the information needed to present a single row. So in this case you are using a wrapper which contains multiple domain objects and some trivial data ...
- wouldn't it be cleaner to have a specific view model for that specific rsult page which only contains the necessary to be shown data?
- And don't you hate it in a JSP or so when you type 'objectX.fieldY' and for some reason in time fieldY doesn't exist anymore crashing the system ... I know what refactoring is, but you must admit for non java related sources it does not always works 100%

Here's some other post I wrote in responding to almost the same scenario presented to justify DTOs. On top of that, I'd say that, yes, it would be cleaner to have a specific view model, but that kind of cleanness should not come at the price of a fragile service API/implementation (unless justifiable by some significant performance gain). In other words, I would assemble the view model from DO's in my presentation layer, not the service layer - which makes it just a view model, not a DTO.

[debasishg]

Repositories have a different granularity than DAOs: there's usually one repository per aggregate root, because root entities are the only one with independent lifecycle, while other entities should be "saved" and "retrieved" through their relative root entities.

Very true.

I usually inject repositories, because:
1 - Their interface is expressed in terms of domain entities.
2 - They usually implement business behaviour that must happen when making CRUD operations.

However, repositories and DAOs can be implemented as the same object, i.e. using the Separated Interface pattern: so, what's your way of implementing repositories and/or DAOs?

I also use injection of repositories for complex aggregates. But I must admit that for simple entities, I sometimes use the DAO directly. For complicated aggregates, repositories contain domain logic in addition to accessing the DAOs for data fetching purposes. And the contract for the Repository nicely abstracts away all these complications from the actual entity. From that point of view, ONE repository can *contain* MULTIPLE DAOs, each corresponding to the respective table in the database. And finally, I use interfaces as the contracts for repositories .

Cheers.
- Debasish

[rebornspirit]

Regarding Wicket and GWT : it is true that they "easily" let you code complex UIs, but they have IMHO a great flaw : they make separation of concerns useless, forcing developers to produce a lot of Java code.

Could you elaborate on what you think is wrong with the GWT separation of concerns?

Why need developers need to produce a lot of code, those full bloated JSP pages aren't a pretty sight either ... but you have to write something don't you a gui doesn't appear on the screen with some magic trick. But if you need to decide between JSP, tags, ... or a fully maintainable, testable GWT, I think I'm going to take the GWT road, I've made just TOO many complex business web apps to not see the GUI creation / maintenance / testing problems. Things tend to get more complex every project, and I don't thing fighting complexity with a scripting or tag related language is going to help us lowering time-to-market.

It's not clean to keep the complete session open

Why do you say that?

Hibernate is a persistence strategy and keeping the principles of layered designs in mind being the bottom layer should not be depended on the top layer, well ... keeping the session open in the view gives you a dependency on your persistence strategy, what if you switch to JDBC or iBatis, you will need to make adjustments to your view layer, no?

Repositories have a different granularity than DAOs: there's usually one repository per aggregate root, because root entities are the only one with independent lifecycle, while other entities should be "saved" and "retrieved" through their relative root entities.

I also use injection of repositories for complex aggregates. But I must admit that for simple entities, I sometimes use the DAO directly. For complicated aggregates, repositories contain domain logic in addition to accessing the DAOs for data fetching purposes. And the contract for the Repository nicely abstracts away all these complications from the actual entity. From that point of view, ONE repository can *contain* MULTIPLE DAOs, each corresponding to the respective table in the database. And finally, I use interfaces as the contracts for repositories

I'm old school, like to see things instead of reading abstract explanations about something ... so ... could you provide us a few lines of code showing exactly how you use the dao and how the repository combined with your domain model? Thanks ;-)

Here's some other post I wrote in responding to almost the same scenario presented to justify DTOs. On top of that, I'd say that, yes, it would be cleaner to have a specific view model, but that kind of cleanness should not come at the price of a fragile service API/implementation (unless justifiable by some significant performance gain). In other words, I would assemble the view model from DO's in my presentation layer, not the service layer - which makes it just a view model, not a DTO.

That was exactly what I was talking about, or at least was thinking of :-) Working with DTO's / view models (or whatever name is may have) will force you to have its own layer on top of the service layer. A layer which is responsible for assembling view models out of multiple domain model data retrieved from multiple service. I'm doing this currently for my GWT application, my GWT app does ajax calls to my application services, which are responsible for assembling my view models. It looks very clean and having done multiple years of business web apps I know the hell of changing domain models which cause views (jsp or so) to break or at least hard to maintain.

Some other random thoughts
- So you have designed the company business into your domain model, it all looks great, the idea will serve for years... BUT (yes there is always a 'but' in IT lolz) business rules tend to change faster than project can be completed. So what about using domain models in combination with rule engines i.e. Drools, anyone has any good or bad experiences with that?

[debasishg]

Here are some of my thoughts regarding injection of DAOs or Repositories in domain entities ..


Cheers.
- Debasish

[gmatthews]

I was wondering if some of us actually tried to implement DDD? Or are we still where we were in 2005?

Seems like if there was a good way to *implement* it rather than write about it then we'd all be doing it by now.

The @Configurable approach arguably just creates an AOP injected Ball-Of-String (AOP BOS)

The furthest we've taken DDD is to implement methods which can make use accessible Hibernate properties (many-to-one, set, etc,), so if for example a Hibernate domain object method would otherwise need a DAO injected we put the method in the DAO, not the domain object (anti-DDD).

[Nik]

Hi,

I am also a struggling recoverist from acute anemicdomainsm trying to grasp DDD (especially in the mvc/spring/orm context). I tried to partially implement a very simple domain with an Order which can add OrderRows based on Products. The "core" method in Order looks like this:

	public void addOrderRow(String productName) throws DuplicateProductException, OrderAlreadyProcessedException {
		if (productAlreadyInOrder(productName)) {
			throw new DuplicateProductException("Product " + productName + " already in order");
		}
		if (orderAlreadyProcessed()) {
			throw new OrderAlreadyProcessedException("Order " + orderNumber + " is already processed");
		}
		Product product = repositoryLocator.getProductRepository().fetchProductByProductname(productName);
		OrderRow newRow = OrderRowFactory.createRow(product, rows.size() + 1);
		rows.add(newRow);
	}

* Should the Product added be looked up by the Order or should the caller pass in the looked up Product?

* Should the row number be passed to the OrderRowFactory in that way?

And the calling action looks something like

	public void addProductToOrder() {
		try {
			currentOrder.addOrderRow(selectedProductName);
			serviceLocator.getPersistenceService().persist(currentOrder);
		} catch (DuplicateProductException e) {
			e.printStackTrace();
		} catch (OrderAlreadyProcessedException e) {
			e.printStackTrace();
		}
	}

* Should the persistance be the responsibilty of the callee?
* Should the repositories do all their DB access through a DAO or can they have a DAO-like implementation themselves? (please see attached code)

Please see the attached zip for "complete" source. e.g. it compiles but hasn't been run in any way. JPA and spring mappings have been left out and there are many simplifications but hopefully you get the point. The post would be too long if I posted them all in text.

Am I at all heading in the right direction regarding the design and dao/repository/service concepts? Comments are appreaciated!

[Andreas Senft]

* Should the Product added be looked up by the Order or should the caller pass in the looked up Product?

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

* Should the row number be passed to the OrderRowFactory in that way?

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.

* Should the persistance be the responsibilty of the callee?

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.

* Should the repositories do all their DB access through a DAO or can they have a DAO-like implementation themselves? (please see attached code)

As I see it, "repository" and "DAO" are practically the same.

Regards,
Andreas

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

<Edit>
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.
</Edit>