A common challenge in Service-oriented architecture (SOA) is the design of service contracts. Beside many variations we see two basic types of contracts.
Forms over data (FOD) is an approach in which the forms in the user interface directly reflects the data structures in a database. The service-layer, if present, primarily offers create, read, update and delete (CRUD) operations for the individual database entities.
FOD is fostered by technologies such as Microsoft Access, Oracle Forms, .NET RIA Services. In JEE it is recognized as an anti pattern addressed by design (anti-)patterns such as Face Off or Session Facade.
FOD is tempting because large parts of the service-layer can be generated from an existing data model. By using the right tools, developing an FOD-application can be quick and easy.
Domain driven design (DDD) is an approach that utilizes a service-layer whose data objects are inspired by the business domain. The database structures are hidden behind a service-layer and not known by the service consumer, for instance the user interface. The domain model is usually modeled using XML Schema. DDD is typically used in SOA environments.
DDD-Pros
- Portable domain model – If modeled in XML-Schema the domain object can be generated on JEE, .NET and other platforms.
- Business alignment – A business oriented domain model can be better understood by business users, thus increasing agility.
- Higher degree of reusability – Services representing business concepts are more likely to be reused, for instance in BPM environments.
- Decoupling of user interface and database – Data structures can be changed (up to a certain degree, of course) without affecting the clients. Changes can be handled in the service layer.
- Maintenance – Proper domain driven services are designed to last. Paired with a versioning approach service maintenance can be simplified.
FOD-Pros
- Development effort – FOD is often supported out-of-the-box in many products, so that no using it would require more knowledge and development effort.
Although there are always areas in which one or the other approach makes more sense, you can clearly see my preference. I think forms over data can be particularly useful for small applications and prototypes. Especially with existing database models. For large enterprise applications one should prefer a domain driven service design in combination with a sound SOA approach.