SOA and DDD

Hot on the heels of The Death Of SOA and The Wake For SOA, the debate on what constitutes SOA continues. Phillip Calcado asks a fairly fundamental question: What is a Service?

There are many definitions for SOA and Services and I don’t think I fully agree with anything I’ve read in this topic. I’ve worked with multiple flavors of distributed components in the pre-SOA days and can’t see much difference between what people use to define SOA and the resources already available in Component-Based Design.

In Phillip's view SOA is "about reducing noise in architecture" and using components that are "part of the business". Which leads him to the view that SOA is Domain-Driven Architecture. Phillip goes on to describe a business engagement he was involved with that helped to solidify his thinking around this. This involved a client believing that they needed to buy a new billing system because the ones that they currently had in place were hidden behind other business applications and not exposed as first class citizens to other applications.

In this case was that the architecture didn’t reflect the business. For sure there are constraints in what and how you expose things when you are a vendor of an expensive product. If we focus only the technical aspects of the problem, though, I would suggest that if we intended the business people to think about the billing feature as something they can use when designing their strategies we should make it a first-class citizen.

In the discussion he makes the claim that:

The technologies behind SOA are pretty much the same technologies used in good old Component-Based Design. A lot of what we do today using Services could be done using component technology. The main difference is the mindset, components were often created by technicians and used by technicians. Services have a broader user base.

This matches what Jack van Hoof had to say when he also asked the same question.

So, is a software component a Service and is CBD (Component Based Development) the same as building a Service Oriented Architecture? Not quite, it is the other way around: A Service in an SOA (as SOA is currently understood) is a software component, but a component with a strong business function constraint. SOA is an instance of a component based architecture. So building an SOA has always to do with CBD, but CBD has not always to do with building an SOA as we understand an SOA.

But Phillip goes one step further and believes that the architecture needs to be in a language that developers and stakeholders (aren't developers stakeholders?) can understand.

Just as it happens at the design level, getting a Ubiquitous Language for the architecture of a system requires some work. Nevertheless I would say that it is probably easier to work based on the Domain-Driven Design principles at the architecture level as architectural components often directly impact business -they are more tangible- something that is not true about most classes and objects.

This is where Domain Driven Design comes in: "A Service should be the implementation of a concept that the user understands." Phillip then uses an email example to illustrate what he means, but the central concept is that the services in the application need to match what the end-users expect rather than what the developers may think or what the low-level system provides.

What is important is to define a service that is part of how your user thinks about his tasks. Only if the API user fully understands the language you are using when defining your Services you can achieve your goal of opening up your system. Even if you supply them with a detailed manual the amount of translation required between the way they think about your service (often imposed by how your user interface looks like) and how you implement it.

But let's give the final word on what constitutes a service to the OASIS SOA Reference Model standard, which does echo a lot of what Phillip and Jack have said:

The noun “service” is defined in dictionaries as “The performance of work (a function) by one for another.” However, service, as the term is generally understood, also combines the following related ideas:

• The capability to perform work for another
• The specification of the work offered for another
• The offer to perform work for another

These concepts emphasize a distinction between a capability and the ability to bring that capability to bear. While both needs and capabilities exist independently of SOA, in SOA, services are the mechanism by which needs and capabilities are brought together.

In the comments section of Phillip's posting there is some disagreement as to whether what he describes is right, with one commenter saying:

I don’t think one can say what you describe is THE correct definition for SOA, just because when everyone has her own truth, there’s no real one truth. But this post contains one of the most USEFUL definitions of SOA I’ve seen so far.

But another isn't quite so sure:

I think the ideas around SOA are out there though and personaly I’d far rather talk about good business-focussed SOA (Steve Jones style perhaps) and then dig into the domain models. In doing so we might take some ideas from DDD directly (UL) and we might use other ideas to shape/describe our services (context maps/bounded contexts/etc) but I’m still hoping someone steps up and writes a similiar book about SOA some time soon.

What is clear though is that as long as there remains uncertainty as to what constitutes a service how can we expect SOA to deliver? Or maybe this is an isolated case and everyone else really does understand "what's in a service"?