Merging service layer and DAO layer into single layer

[juk]

Unfortunately, people just love to label things. Labels later may become buzzwords, and, eventually, there will be situations when the common sense gives way to some blind dogma following and buzzword-joggling. Domain-driven design is a great thing. But it should not mean that one single object should know everything about itself including how to store itself (even if it only means storing a reference to a storage mechanism.)

The object don't know how to store itself, thats wrong. It have a reference to another domain member, the repository. The repository is part of the domain. The object only knows that there is a repository (and it can be anything that implements the repository interface).

In the real world, things don't have any built-in notion of the location they are supposed to come from. An orange is an orange regardless of whether you picked it directly from a tree, or from a shelf in a grocery store. When you describe the qualities of an orange it would be ridiculous to add the notion of its storage. Well, if you describe a grocery store, than maybe you will have to include some way to point to a location where oranges can be found. But that would be a whole different subject, an external context.

Exactly. On your example on a DDD approach, the orange does not know about any tree or shelf. It only knows about the repository (domain). On your example you can change the 'tree' to a 'DAO'. On DDD the object does not know about the DAO or watherver mechanism do be stored, so your example is wrong. He knows only about other member of the domain, the repository.

Entities in the Domain model are just things, items.

Wrong. On the domain model, things are value objects. Entities should be identified and stored.

Someone may decide to store them somewhere, but that has nothing to do with the nature of the item itself. Do not make things in software more crafty then they have to be! Many people think its smart and sexy to put all those notions into a single class. I think it is NOT. Sometimes, you will make things quite convenient for yourself - in one particular context. But it may render the object completely not applicable in other contexts.

In any context an entity it should be stored and have an identification. If it does not have it, it is not an entity. So in any context an entity should have a repository. It is not tied to a DAO or anything.

Often, it makes things less natural, and therefore, more complicated and convoluted. I am all for DDD. Except I define a functional Domain as a combination of domain entities and domain operations/use cases that may (or may not, depending on the circumstances) be applied to those entities. Services are also objects in the Domain system. They are the objects that encapsulate the business operations, the use cases.

Services do not encapsulate use cases. Services encapsulates business logic between object interations. All business logic that belongs to one single object should be placed there. If you place this logic on the services you will probably have duplicated code, since when you are developing a new service you will reuse business logic placed on the object, and not in other service (maybe you doesn't know other services at all).

Such operations, in my opinion, absolutely must be de-coupled from the essential properties and behavior of the entities/actors in the same Domain. There is no violation of OO principles here at all. It is all about the appropriate and thoughtful de-coupling of things and concerns that should not be molded together. I am sure that in many cases you can put everything into a single object and it will work fine. But such object becomes less generic, and your whole domain model becomes less flexible and specific to a given set of circumstances. This is not my idea of software architecture. I prefer less assumptions, less dependencies, more flexibility and compartmentalization of concerns and functionality. And I can say the same thing: it has worked very well for me.

We are not putting everything in the object. We are putting everything that belongs to the Entity on it. It is not less generic, since a Repository is a member of the domain and you are not making your Entity dependent of any concrete classes (like a DAO, or a tree). It is not less flexible at all.

[constv]

A data source - or any abstraction of it - is NOT part of the domain, sorry. That's just wrong. And that weird assumption is the basis of the repository pattern, as well as of all your arguments. In addition, you have misinterpreted and twisted every single thing I said, and I see no point in arguing with you.

[juk]

A data source - or any abstraction of it - is NOT part of the domain, sorry. That's just wrong. And that weird assumption is the basis of the repository pattern, as well as of all your arguments.

From Domain Driven Design Quickly:

"It can be noted that the implementation of a repository can be
closely liked to the infrastructure, but that the repository
interface will be pure domain model."

If you dont think the repository is part of the domain you disagree with a big part of the DDD concept.

In addition, you have misinterpreted and twisted every single thing I said, and I see no point in arguing with you.

Sorry, but you said you read the DDD book and said that you agree with it (only disagree with Repository), but your concept of Entity is very wrong. You described an entity exactly how DDD describes a VO. And I agree, there is not point arguing with you too, since I dont think you ever read a DDD book in your life and you are posting blind opinions like Gavin King did.

[constv]

but you said you read the DDD book and said that you agree with it (only disagree with Repository), but your concept of Entity is very wrong. You described an entity exactly how DDD describes a VO. And I agree, there is not point arguing with you too, since I dont think you ever read a DDD book in your life and you are posting blind opinions like Gavin King did.

Nonsense. Of course, I have read that book, and I have never said that I agreed with everything in it. I don't blindly follow everything I read. A lot in that book did not sit well with me, and yes, my concept of entity is different - obviously - from the DDD book. The book is your bible, not mine. I said that I see nothing wrong with DDD, except my vision of DDD is not exactly the one the book offers. And that does not make my approach wrong. It's just too arrogant and immature to state that. Tells more about you than you think.

My "entities" have nothing to do with VOs, because I have always advocated putting behavior inside entities, not just data. (If you had read this very thread instead of skimming it, you would have noticed that.) Except, I believe, such behavior must be the kind that makes up the essence, the nature of the entity, not the business logic. I also think that it is incompetent to state that each "item" represented by an class must be a persistent object in its own right. Many don't have to be. And it is wrong to approach application design (or object modeling) from the persistence point of view, as many people mistakenly do. Persistence is just one concern that may or may not be part of a use case. And the public interface exposed by Domain (the kind that is accepted by the school of thought i belong to) should only represent the logical use cases, nothing else. Not the fact that something gets saved, but what actually makes sense to the client of the service. If you are placing an order on the web site, you don't think of saving something in the database, you are thinking of pressing a button and expect theh product delivered to your door in a few days. That's the use case. The implementations may be whatever, the clients should not care. You should not even have APIs like "saveOrder". Instead it should state "placeOrder", or submitOrder.

We have discussed these subjects to death in this forum, the differences between various approaches, including the Evans book - long before you showed up. Many people here have read many books, not one, and have built many successful and practical projects, using various philosophies and methodologies - before they came to certain conclusions on their own, based on education and experience, not dogmas. So, if you are here to offer your opinion, suggestion, or, better yet a working solution, you are very welcome. If you are here to tell me that you've read a book, and everyone who disagrees with it or doesn't take it as a bible is dead wrong, you need to grow up.

[juk]

Nonsense. Of course, I have read that book, and I have never said that I agreed with everything in it. I don't blindly follow everything I read. A lot in that book did not sit well with me, and yes, my concept of entity is different - obviously - from the DDD book. The book is your bible, not mine.

It is not my bible. I just agree with most of it, and thats completly different.

My "entities" have nothing to do with VOs, because I have always advocated putting behavior inside entities, not just data.

I was talking about DDD VOs, and they are not just data. On DDD, VOs have business logic. Maybe you are confused about DDD VOs and other VO pattern (the old DTO).

We have discussed these subjects to death in this forum, the differences between various approaches, including the Evans book - long before you showed up. Many people here have read many books, not one, and have built many successful and practical projects, using various philosophies and methodologies - before they came to certain conclusions on their own, based on education and experience, not dogmas. So, if you are here to offer your opinion, suggestion, or, better yet a working solution, you are very welcome. If you are here to tell me that you've read a book, and everyone who disagrees with it or doesn't take it as a bible is dead wrong, you need to grow up.

I am sorry, but I am only giving my opinion. On this thread, and on other threads, you say many things are "wrong" and I see it as your opinion, not as a dogma. I am just defending things that I believe are correct and saying that I have success with it, not saying that it is correct.

I disagree with some points on the DDD book, but not the reps/services concepts. It is not my bible at all.

[shahnawazshahin]

Just to add to this, doesn't the Template Method design pattern ring a bell? Adopting this pattern means usually the domain and dao layers are usually roled into one. This is a common pattern and is widely accepted.

Having the domain and dao layers separate usually means that the Strategy design pattern is used. This is more popular. You'll find that the use of the Strategy pattern is more flexible to use and is helpful when developing large scaled apps.


Shah.

[rsahoo]

I was searchig for a solution to exactly same problem. After a long time, came up with this solution utilizing dynamic proxy and spring FactoryBean interface. Find the solution at this link (i.e. my blog) http://ramesh-sahoo.blogspot.com/

[dams50]

Very nice thread.

Actually, i found it, as i was naively wondering if the use of JPA (instead of IBatis) had an impact on the good old architecture (presentation -> service -> DAO).
Eventually, i was wrong doubting this architecture viability just because of an other data access implementation. That's what not also this thread tells me, but my common sense also at the end.
We are often get so troubled facing with new techno, that it sometimes makes you confused and losing your beliefs. This thread has the advantage of replace things to their right place. To say, counting on his own experience and not dogmas, not focusing on technology mermaids but using it as a mean not an aim.

Thanks for reminding me the cape, captain CONSTV !!

[akarypid]

Hi,

I'm also struggling with the "proper" DDD-way of doing things. By proper I mean finding out how it fits into the rest of the world, rather than dogmatically applying everything I find in the net. I think we need to discuss more specific topics to gain a better understanding.

I'm still half-way through the book and here's my take on things:

My understanding is that DDD is all about your business tier. It doesn't mention much (at least as far as I've got) about other aspects such as the presentation/services tier.

I'd expect that writing a DDD application is not so different in those regards, other than the fact that perhaps you've moved some (or a lot) of business logic into the domain and there's less in the services tier.

So here's one concrete question: How do you handle transaction demarcation in DDD?

Let's say you have methods on your domain objects that allow them to (agnostically) access persistence through repositories. Who do you allow to make such calls? Do you make the domain object @Transactional and allow anyone to use them (e.g. even the presentation tier)? After all, what's the point of having an order.save() method if the controller has to go through a service to use it? But isn't that a violation that pollutes the domain model with persistence implementation information? Ok, it's just an annotation, but the domain object suddenly becomes able to define a transaction boundary for some code path that ends up invoking a DB/JMS/... resource that it is unaware of.

Coming from a "traditional" background, I favor clear separation and require that client code (e.g. presentation tier code) goes through some transaction boundary (e.g. a @Service in your services tier). The result of my approach was that after injecting "repositories" into my @Configurable domain objects, I couldn't get to them from my presentation tier unless I violated my principle of starting transactions at a clearly-defined boundary in my application... So I tried to keep the transaction boundary and realized that I must have taken a horribly wrong direction when I started writing stuff like:

Order order;
// ...
pubic void handleButtonPressInPresentationTier() {
     // order.processOrder(); <-- this would fail as it's not @Transactional
     orderService.submitOrder(orderDomainObject); // this is @Transactional
}

But then in the services tier:

// this service class is @Transactional

// ...

pubic void submitOrder(Order orderDomainObject) {
     orderDomainObject.save(); // ends up calling repository
}

So then, why not inject the repository into the service and NOT have a save() method in the domain object?

Perhaps a middle ground would be to have domain objects annotated as @Transactional(propagation = MANDATORY). Then you can indirectly use resources at the domain object level (via the repository), while at the same time preventing direct access from any entry path (calling into the repository via the domain object requires that the client has already started a transaction, which is documented in the code via the annotation)...

Then again, perhaps I'm still too "transaction-script-oriented" and am missing the point?

Any comments on the above would be appreciated.

[constv]

akarypid, you bring up valid points. Not to revive this [at times somewhat inflammatory] thread, here's a "brief" answer:

Transaction management is an application concern, not a domain concern... quite obviously. That is why it belongs in the "application layer" (the exact term used by Eric Evans, btw.) I personally have expressed my point of view many times in these forums: I don't think that persistence should be part of the Domain. In my opinion, it is very much an application-layer, use-case concern/implementation detail. DDD does not mean that all logic and persistence operations should be part of domain entities. It is the "DDD zealots" who, I think, take the idea way too far and fail to separate the essential object behavior from the application-specific logic that should - not contrary to what Eric Evans states in his book - live in the application layer. Services and repositories are part of the application layer. A domain "service" (or whatever you prefer to call an object that implements the logic that does not fit one particular domain entity but rather governs multiple domain entities in a context of particular application use cases) is the perfect point for transaction demarcation and domain-level security. (BTW, I would recommend defining transactions on the method level rather than on the class level.) Being part of the application infrastructure, repositories (or DAOs) should normally be abstracted within such "domain services." Spring provides very convenient stereotype annotations for such classes (@Service, @Repository, etc.) Note that none of this goes against the DDD principles. The most important thing, in my opinion, is to always properly separate the domain entity-level behavior from the application use-case level behavior. Failure to do so will result in a rigid domain model not reusable among applications within even the same enterprise. Implementing application use cases involves - usually - more than one domain class, may include transactional and secure operations, and should be implemented outside any given domain entity. That's what domain services (or whatever you want to call them if you hate the word "service") are for.

HTH,
Constantine