14 Jul 2009

Agile SOA: WSDL Generated code is not Domain Model code

Over the last 5 years I've worked with companies attempting to combine Agile software development with SOA. From the software development point of view, one of the biggest challenges I've seen is dealing with the conflict arising from "WSDL First" generated code and the reliance on "good code", simple design and automated testing central to Agile software development.

Strategic Service Oriented Architectures (based around WS-* specifications) are usually created "WSDL First". Helper code (normally Java) is generated from the WSDL to allow programmers to build and interrogate service messages programatically.

In an SOA, the WSDL contract is normally based on a solution wide canonical data model. It is tempting to think of the generated code as domain entities. This results in an anemic domain model where domain logic normally residing in domain entities must live in other objects. The reduced cohesion, increased duplication and test complexity results in brittle services that don't cope when service contracts change (they invariably will).

Instead, we should recognize that from the service implementation perspective the generated code represents data transfer objects. When we completely isolate those DTOs (in an anti-corruption layer) we are free to evolve simple (POJO) domain objects resulting in simple, flexible and easy to test service implementations.