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.