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

Domain Logic

[The Anemic Domain Model] [n]ecessitates a separate business layer to contain the logic otherwise located in a domain model. It also means that domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).

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

but...

[Some are] just technical constraints, according to Dahan: “The business doesn’t care that username fields are 8 characters. Usernames have to be unique for technical reasons to be able to select customers to check details”. Rules that are not part of genuine domain logic do not have to be implemented in the domain model, suggested he, because they do not model the domain. They may be deployed to a separate tier.

http://agile.dzone.com/news/biggest-mistakes-teams-make

Udi again:

Validation of string lengths, data ranges, etc is not domain logic and is best handled elsewhere (and a topic for a different post). The same goes for uniqueness.

http://www.udidahan.com/2009/06/29/dont-create-aggregate-roots/

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

Domain Model vs. BLL

Just to be clear, I like to think of a Business Model and Business Logic as two separate layers. Your business model are your POCOs (Plain old CLR objects). Your business logic layer would be responsible for performing validations, transactions, etc using both your business model and an interface to your DAL that could be wired up a number of ways (Spring, Castle, or your own home grown IoC container).

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

I'd like to remove the coupling to allow us to support different address repositories as we can with the .Save within our CustomerRepository (via RepositoryFactory). I'd also like to remove any knowledge of repositories from my domain objects. Although it isn't always possible I prefer for application code to have knowledge of repositories NOT my domain objects.

 http://web.archive.org/web/20100420152400/http://steve.emxsoftware.com/Domain%20Driven%20Design/DDD%20Reconstituting%20objects%20from%20multiple%20Repositories

Business Logic

In addition to field-level validation, there may be high-level custom business rules that involve different entities or concepts not expressible at the single column level, such as:

• If a product is discontinued, its UnitPrice cannot be updated

• An employee's country of residence must be the same as their manager's country of residence

• A product cannot be discontinued if it is the only product provided by the supplier  

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

• In the DataMapper pattern you have one domain object that holds all the business logic, for exmaple user.getLinkToProfile() (or something similar) but knows nothing about the database in question, in addition to this you have a mapper-object that is responsible for saving, updating, selecting, etc. user objects from the database which would have UserMapper::find(1), UserMapper.save(user)

  thr - http://stackoverflow.com/questions/93773/how-does-the-activerecord-pattern-differ-from-the-domain-object-or-data-mapper-p

A Service Layer defines an application's boundary [Cockburn PloP] and its set of available operations from the perspective of interfacing client layers. It encapsulates the application's business logic, controlling transactions and coor-dinating responses in the implementation of its operations.

http://martinfowler.com/eaaCatalog/serviceLayer.html

Operations such as account.AcceptTransaction(transaction) and account.CalculateCurrentBalance() are domain logic which should go on those very same anemic entities.

George Mauer - http://lostechies.com/jimmybogard/2009/12/03/persistence-model-and-domain-anemia/

Each interaction between a client system and a server system contains a certain amount of logic. In some cases this can be as simple as displaying information in the database. In others it may involve many steps of validations and calculations.

http://martinfowler.com/eaaCatalog/transactionScript.html

...your code should either be in the business of doing business logic or in the business of instantiating and wiring other objects together. What this effectively means is that your either have classes with ifs and loops (your business logic) or you have classes with new operators (your factories).  

http://misko.hevery.com/2009/03/30/collaborator-vs-the-factory/

 ...They might, for instance, when changing the sex of an employee, have to go over to the health insurance screen and mark that the person does not need prenatal care. That's what the software is supposed to do for you! That's business logic.

Gregg Young Presentation - http://skillsmatter.com/podcast/design-architecture/architectural-innovation-eventing-event-sourcing/

Presentation Logic vs. Business Logic

How do you know which logic goes in which tier? There is no absolute rule, but a good rule of thumb is the following: If it's a piece of logic that might be executed no matter what type of UI (Web or Windows), it probably should be coded in the middle tier.

http://www.informit.com/articles/article.aspx?p=22679&seqNum=3

The EXEC CICS RECEIVE and EXEC CICS SEND MAP commands are part of the transaction’s presentation logic, while the EXEC CICS READ UPDATE and EXEC CICS REWRITE commands are part of the business logic.

http://publib.boulder.ibm.com/infocenter/cicsts/v2r3/index.jsp?topic=/com.ibm.cics.ts23.doc/dfhp3/dfhp3pu.htm

The part of an application program that performs the required data processing of the business. It refers to the routines that perform the data entry, update, query and report processing, and more specifically to the processing that takes place behind the scenes rather than the presentation logic required to display the data on the screen (GUI processing).

 http://www.pcmag.com/encyclopedia_term/0,1233,t=business+logic&i=39074,00.asp

[S]ome duplication, especially for validation purposes should exist in the client as well. Such rules should be reinforced by the business layer.

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

Domain Model

A domain model can be seen as an interface or a pipe between the Requirement Engineering phase and the Design Phase of the software development life cycle.

http://www.site.uottawa.ca/~ssome/UCEdWeb/publis/domainGen.pdf

Rule of thumb: If you are passing around primitive data types among object collaborators, it may be an indication you are not communicating at the right level of abstraction. You need to see whether the primitive data types represent concepts in your domain that you may have missed. 

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

Let’s begin by using slightly different names. Let’s call the model of data that you persist the domain model and call the data you manage in the view the view model. I should mention that domain model isn’t exactly a neutral term in software, as it refers to an object model designed according to a number of additional rules. In the scope of this article, I’m not using the meaning that results from the Domain-Driven Design (DDD) methodology. For me, here, the domain model is simply the object model you persist—entity model might be another equivalent—and less confusing—term.

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

I'll just add that at the heart of the application, there isn't necessarily *a* Domain Model, but possible *some* Domain Models.
The same application can have several aspects, or contexts, that might be modelled differently.
the cool stuff - all aspects might share the same storage mechanism (i.e. RDBMS tables), and it would fit perfectly in the Domain-driven Onion modelling of the system

 Ken Egozi - http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

GUI will ask Repository to get domain object by id.. and once GUI has the domain object you could navigate it to reach other objects.. This way Domain layer does not need to know anything about repositories..

 StackUnderflow - http://www.techques.com/question/1-458098/Business-Logic-Layer-and-Data-Access-layer:-circular-dependency see also on idea of splitting BLL into Service/Business Logic Layer and Domain Model Layer

• We'll have a richer domain model which contains state, relationships, and logic inherent to the objects in that domain model.
   http://stackoverflow.com/questions/4708689/ddd-where-to-put-persistence-logic-and-when-to-use-orm-mapping

The Domain Model is a self-contained component – it doesn’t take dependencies on anything else. What it does is raise events that external code can use to make decisions about which external “service” to call.

http://www.udidahan.com/2008/02/15/from-crud-to-domain-driven-fluency/

The definition fat model means having as many domain objects as needed. Be it reports, validators, filters, entities, strategies and so on.

http://www.thedeveloperday.com/skinny-controllers/

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 BLL

Within a BLL objects can further be partitioned into business processes (business activities) and business entities. Business process objects typically implement the controller pattern, i.e. they contain no data elements but have methods that orchestrate interaction among business entities. Business entities typically correspond to entities in the logical domain model, rather than the physical database model. Domain entities are a super-set of data layer entities or data transfer objects, and may aggregate zero or more Dies/DTOs.

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

[I]n many cases [the BLL is] just the bridge in between the presentation layer and the data access layer with having nothing much, except taking from one and passing to the other... The business entities should meaningfully define considering various types of requirements and functioning of your system. It is recommended to identify the business entities to encapsulate the functional/ UI (User Interface) requirements of your application, rather than define a separate business entity for each table of your database.

http://www.codeproject.com/Articles/22769/Introduction-to-Object-Oriented-Programming-Concep#three-tier

Business Rule Layer
This layer is implemented in order to encapsulate your business rules. If you have followed best practices, you will have created a set of documents which describe your business. In the best of cases, you will have a set of use-cases describing your business in precise detail. From this you will have been able to create a class association diagram which will help you create your business layer.

Here we find classes which implement your business functionality. They neither access data (except through the data layer) nor do they bother with the display or presentation of this data to the user. All we are interested in at this point are the complexities of the business itself. By isolating this functionality, we are able to concentrate on the guts of our system without the worry of design, workflow, or database access and related concurrency problems. If the business changes, only the business layer is affected, again considerably simplifying future maintenance and/or enhancements.

http://www.dotnetspider.com/forum/166048-use-n-tier-architechture.aspx

It's also worth emphasizing that putting behavior into the domain objects should not contradict the solid approach of using layering to separate domain logic from such things as persistence and presentation responsibilities. The logic that should be in a domain object is domain logic - validations, calculations, business rules - whatever you like to call it.

http://martinfowler.com/bliki/AnemicDomainModel.html

  In the very center we see the Domain Model, which represents the state and behavior combination that models truth for the organization. ... the Domain Model is only coupled to itself.

  http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

[W]e have decided that Castle Validators are a natural fit for validating data integrity of the EditModel (the type being bound by the model binder when a form is submitted to a controller action).  This is not business rule validation.  This is merely things like: “can the characters that were submitted be parsed into a date, an int, a guid”, etc.  Once we get passed data type validation, then the domain model can work on the more interesting business rules.

 http://jeffreypalermo.com/blog/you-should-not-use-asp.net-mvc-if/

Business logic is the if statements and the loops and the stuff that actually does work...

Miško Hevery - http://www.youtube.com/watch?v=wEhu57pih5w

This offers an excellent benefits in real word scenarios where you have certain methods on an entity that return an IQueryable of T and some methods return List<T>. But then you have business rule filter that needs to be applied on all the collection regardless if the collection is returned as IQueryable of T or IEnumerable of T. From a performance stand point, you really want to leverage executing the business filter on the database if the collection implements IQueryable otherwise fall back to apply the business filter in memory using Linq to object implementation of delegates.

http://weblogs.asp.net/zeeshanhirani/archive/2008/07/31/using-asqueryable-with-linq-to-objects-and-linq-to-sql.aspx

The presentation (that is, the codebehind or controller class) references the application logic, namely a component that implements the application’s use cases. The application logic technically belongs to the business layer or tier, and in very simple cases may be merged with the presentation. This is what happens in some tutorials that are either too simple to really feel the need for isolating application logic in its own layer, or poorly designed and splitting application logic between the presentation and the data access layer (DAL).
 
The application logic 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

Remember that the business logic in Microsoft Dynamics AX can be used though COM from other applications. For example, an X++ script can access the business logic that creates a sales quotation. This underscores the importance of not letting the business logic be dependent on a specific Microsoft Dynamics AX form or report.

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

In deleting a customer however there are many business logic decisions to be taken. Can the customer be deleted? What are the processes that must be performed before and after? What are safeguards that must be checked first? From which tables the records are to be deleted, or updated as a consequence? ... [re phone numbers] It is important that although it is formatting, it's not user interface, and although the urge for any centralization often ends up in the database, this is clearly business logic. Implementing formatting in the business layer eliminates duplicate data, and allows for implementation using a development language rather than shoe horning it into a data language.

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