SOA and the domain model
Frans Bouma touches the architectural topic of object-message mapping (or what Martin Fowler calls Data Transfer Object).
Do we need an domain model when working in a SOA (a.k.a. the moving target of today) environment and hence a way to map SOA's message oriented nature onto the object oriented nature of the domain model? I think it's a matter of context, complexity, personal architectural liking and who was there first, namely the chicken(SOA) or the egg(domain model)?
Context:
- What's a service?
- How do you envision your services?
- Who will be the consumer of your services and to what end/purpose will they be consumed/used for?
Complexity:
- How complex will the logic behind your service to be?
- Exactly how coarse-grained are they (your services) going to be?
- Are you going to reuse the logic inside your service (e.g. in another service)?
- Are you going to reuse that logic in a non-SOA environment?
- Will a domain model allow you to better understand and maintain your logic?
- What's the added value of having a domain model behind your service?
Personal Architectural Liking:
- How did you develop services before the SOA hype?
- Is a service an orchestration of cooperating domain objects or an orchestration of other services and messages, to you?