Do RESTful APIs Encourage Anemic Domain Models?

so it would have been impossible to switch out to another ORM (not that we wanted to)).

That seems wrong. A major advantage of the repository pattern is that you hide the data access logic and that it is easily exchangeable.

So far it feels as though I put my business logic in my domain model and via repositories I would work with the ORM (which ever I chose). However, if I wanted to continue to use the MDA tool for the ORM part of the application, the model created here would be very anemic (i.e not contain any business logic). Similarly if I used Entity framework (.net) or NHibernate for my ORM it too would be an anemic model.? I am not sure where you would put the business logic if I just used NHibernate.

An anemic domain model is considered a bad practice by many, for example by Martin Fowler. You should avoid such a design because such a model leads to procedural design techniques rather than a good object oriented design. You then have data classes and manager/processing classes which means you separated state and behaviour. But an object really should be "state and behaviour".

NHibernate does a great job at persistence ignorance. You can hide away the mapping details in XML or with FluentNHibernate and just write plain POCOs. It's very easy to create a rich domain model with NHibernate. I think you can do that with entity framework and the MDA tool, too. As long as this tool produces partial classes you can extend the generated code pretty easily without having to worry that a new generation might destroy your user-written code.

To cut this long story short. When you use NHibernate, nothing, I repeat nothing, stops you from embracing a rich domain model. I recommend using it with FluentNHibernate and mapping by hand. The mapping code takes only 5 to 10 minutes to write. I suppose that the very same is true for entity framework and that its tools at least create partial classes that are easily extensible.

Am I correct in thinking this way, in other words with DDD all the business logic in the domain and just use the ORM for persistence via repositories?

For the most part you are correct. You should have a rich domain model. Especially when things become more and more complex, it's easier to maintain and extend when you've designed it properly. But do keep in mind that DDD also knows (Domain Layer and Application Layer) Services to implement business logic and Factories to encapsulate creational logic.

I also tend to differentiate business logic into domain logic and actual application business logic. The domain logic is how the domain interacts and behaves while the application logic, which is a completely different layer, encapsulates how the domain is used for the specific use-case/application. Often times I have to update the domain model to support specific use cases and to make it more powerful.

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.