Domain models, objects and SOA

Frans got to the conclusion that we don't need O/R mappers in a SOA world. He argues that a 'Manager' model that provides services to data would be a better choice.

Of course, I agree with him.

When we talk about a domain model we talk about having objects with behavior. You could think that a Manager model just means to take the behavior out of the objects and put it in the manager, but keeping the same object model.

If you do that, then you still won't be able to survive in a SOA world. You cannot use your classes to automatically define your messages, because the structure of the messages may or may not be the same as the one in your classes. You may need to include some fields from different classes but not all of them. You don't want to send a Customer with all its related objects (i.e., a Customer with his Orders).

So, you still need to have a 'mapper' that creates the messages based on the object model.

The other approach is to not to have the object model at all, and map the messages (which have fields from multiple classes or tables) directly to the database. IMHO this is a better approach in most of the cases.

The problem with the behavior-less object model or with mapping directly the messages to the database is what to do with the business logic. Writing the business logic in each 'Manager' will probably lead to redundant code, as you may have to deal with three 'Order' Managers, with a slightly different structure, and you'll need to have three Managers.

I think the answer to that is business rules. We could have a rule that says 'the order date should be greater than today' and have it automatically applied in each Manager that deals with Orders.

Biztalk 2004 has a business rule engine that I still was not able to try, but it may be a step in the right direction.