Domain-Driven Design – How Far to Go with Domain Driven Design?

In hindsight, my question should have been "what is business logic". The answer I was looking for was this:

http://www.codeproject.com/KB/architecture/DudeWheresMyBusinessLogic.aspx#_topicpageref_WhatisBusinessLogic

I also found this entertaining analogy: http://www.dougboude.com/blog/1/2008/03/What-IS-Business-Logic-Anyway.cfm

I've put this on cwiki to prevent up-repping

I think that you are on the right track but it might be easier to understand possible different nomenclature to get a better understanding about the role that each of the layers will play in the architecture.

The Martin Fowler article that you linked where he coined the term, Anemic Data Model was his criticism at the time for transactional based architecture and the trend to push Behavior out of data objects entirely. Being a staunch believer in OOP programming and design it is a valid criticism, as he worries about the sophistication of software devolving back to the days of structs and procedural programming. Personally I feel he is rather alarmist and this will not be a problem if strict architectural adherence to layerd and tiered software design is followed in a stateless and transactional way.

1. Domain layer consists of data objects that have the knowledge and ability to persist themselves to database or file

2. Infrastructure layer This could also be known as your Data Access Layer. Stateless DAO classes will have the ability to fetch data objects.

3. I propose you have a seperate Business Logic Layer. Any and all application logic, special domain logic, interactions with multiple DAO or external web services, integrating third party services to satisfy business rules and all in a stateless transactional way, are all examples of what code belongs here. Sure some of this will simply be a wrapper to a single DAO call, but the seperation of concerns and low coupling is the benefit.

4. Presentation Layers There can be multiple presentation layers but they will typically be the arbiters of stateful communication with your users. A good example of this would be the Controller in MVC architecture. It can maintain stateful interaction, and where business logic operations are required, it should be as simple as calling the necessary transactions to retrieve the data needed or perform the necessary operation. There are different types of presentation as well, a thick client or web server will can call the business logic layer directly, or perhaps the business logic can be wrapped by web services that return the data in a useful form.

5. Service Layers The service layer should be devoid of any application or business logic and should focus primarily on a few concerns. It should wrap Business Layer calls, translate your Domain in a common language that your clients can understand, and handle the communication medium between server and requesting client.

Knowing this and understanding the benefits of why this type of transactional architecture might be useful to you however depend entirely on the type of software that you are building. Also questions about the appropriate number of services are meaningless in this case without a complete understanding of your business and technical requirements. It is a valid approach if you wish to build large highly maintainable, scalable solutions with low coupling. If you are building a smaller application with few business concerns or objectives then perhaps it is overkill.