Project Server

Microsoft's Project Server appears to be a good example of a combination of BLL/DAL and CQRS. See http://msdn.microsoft.com/en-us/library/office/ee767687.aspx

Persistence Ignorance

Your questions and doubts ring an interesting alarm here, I think you went a bit too far in your interpretation of a "rich domain model". Richness doesn't go as far as implying that persistence logic must be handled by the domain objects, in other words, no, they shouldn't know how to save and delete themselves (at least not explicitely, though Hibernate actually adds some persistence logic transparently). This is often referred to as persistence ignorance.
I suggest that you keep the existing DAO injection system (a nice thing to have for unit testing) and leave the persistence layer as is while trying to move some business logic to your entities where it's fit. A good starting point to do that is to identify Aggregates and establish your Aggregate Roots. They'll often contain more business logic than the other entities.
However, this is not to say domain objects should contain all logic (especially not logic needed by many other objects across the application, which often belongs in Services).

 ian31 - http://stackoverflow.com/questions/4708689/ddd-where-to-put-persistence-logic-and-when-to-use-orm-mapping

DAL versus BLL

Also, business logic methods from an application can be mapped to the Data Access Layer. So, for example, instead of making a query into a database to fetch all users from several tables the application can call a single method from a DAL which abstracts those database calls.

http://en.wikipedia.org/wiki/Data_access_layer

We'll start with creating a software architecture composed of a Data Access Layer (DAL) using Typed DataSets, a Business Logic Layer (BLL) that enforces custom business rules, and a presentation layer

http://msdn.microsoft.com/en-us/library/aa581778.aspx

The application logic [BLL] orchestrates the DAL, domain classes and services to pursue the expected behavior. The application logic communicates with the presentation layer through view model objects and communicates with the DAL through domain objects. The DAL, in turn, references the model and the ORM assembly.

 http://msdn.microsoft.com/en-us/magazine/hh456393.aspx

Databases are designed to be very fast and efficient with CRUD operations. They are not designed to format telephone numbers, calculate optimum usage and peak periods of utility usage, determine geographic destinations and routings of shipments, and so on. Yet, I have seen all of these cases, and even more complex ones implemented mostly or even wholly inside stored procedures. ... Which tables are affected is business logic as well. The database should not have any knowledge of which tables constitute a customer on the business level. ... But stored procedures should not do anything other than join data when returning data. For updating data it should do exactly and only that and should not interpret the data in any way.

http://www.codeproject.com/Articles/10746/Dude-where-s-my-business-logic

Description of DAL

All code that is specific to the underlying data source – such as creating a connection to the database, issuing SELECT, INSERT, UPDATE, and DELETE commands, and so on – should be located in the DAL.

[DAL] methods could simply return a DataSet or DataReader populated by the database query, but ideally these results should be returned using strongly-typed objects. A strongly-typed object is one whose schema is rigidly defined at compile time, whereas the opposite, a loosely-typed object, is one whose schema is not known until runtime.

http://msdn.microsoft.com/en-us/library/aa581776.aspx

Thus, your business tier contains logic for retrieving persistent data from the data-tier and placing it into business objects and, conversely, logic that persists data from business objects into the data tier. This is called data access logic.

 http://www.simple-talk.com/dotnet/.net-framework/.net-application-architecture-the-data-access-layer/

The DAL should have no knowledge at all about the Business Logic Layer. It should, in theory, be able to be called from any client. For example, what if you wanted to seperate the DAL from the application and deploy it as a seperate service exposing itself via WCF?
As mentioned, the DAL operations, e.g. SaveNewsItem should be be accessed by the BO via interfaces, perhaps via dependency injection/IoC.

ng5000 H
2009-01-19 16:18:31

Yes, I agree - it is better that the DAL does not know about the BLL. Instead the DAL should have some sort of abstraction so that the BLL can construct its entites from 'raw data' ie DAOs (or XML or a map of key/value pairs for example). These factories are better separated from the domain logic

Tom Carter

 http://www.techques.com/question/1-458098/Business-Logic-Layer-and-Data-Access-layer:-circular-dependency