« SOA Governance Research | Main | SD Best Practices Conference »

Recently a company asked me about a design modeling method for doing domain analysis. Thinking that I actually did know what the term meant I started doing some research and soon realized that there is not actual agreement on the term. The May 8, 2006 edition of Infoworld had a whole section on “Organic SOA: Creating a Sustainable Lifecycle” David Linthicum had an article on domain analysis, and his definition was what I thought I was going to find elsewhere. It was about a top down approach to defining web services.

However, a BEA whitepaper that has been liberally spread across the web that defines six SOA domain: (1) business strategy & process; (2) architecture; (3) building blocks which include both infrastructure services, business services, and composite applications (why aren’t infrastructure services part of architecture and why aren’t composite applications part of projects and applications?); (4) projects and applications; (5) organization & governance; (6) and costs and benefits. This is definitely not a domain model used for designing business services.

Then there is the programmers’ view of the world, which is important because they are the ones to implement this. According to Martin Fowler, a domain model is an object model that includes both behavior and data.However there is now quite a bit of scuttlebutt about an anemic domain model for SOA where the behavior is not there. Apparently some programmers think this is better for SOA design. (See Andres Aguiar and Carols Perez ).

Apparently, a domain model means different things to different people. What does it mean to you? What types of models are you using to design business services?

Posted by bethgb at 11:47 AM in SOA Design | Digg This | Add to del.icio.us