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:
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.
- The capability to perform work for another
- The specification of the work offered for another
- The offer to perform work for another
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"?
Design is more important than definition
Nice write up of an interesting topic, but also includes an issue that we will probably never see resolved in our lifetime -- the definition of a service.
More important than that however is the need to focus on the design of services, and ensure that's correct. The definition of a service may vary according to the goals of a design, but the success or failure of an SOA project depends much more on getting the design right than getting the definition right.
Part of this of course is because SOA is never going to be a "one size fits all" proposition, and like any good methodology, works best when adapted to a particular - domain I guess you could say.
I do believe that's an important contribution here, to add to the thinking about SOA the parallel with domain driven languages and designs.
Re: Design is more important than definition
Re: Design is more important than definition
You are of course right on the design/implementation aspect, however one thing I would say about DDD and SOA is that *if* you are thinking of using DDD for the models internal to then services then using a business-centric approach when modelling your services/capibilities probably also makes sense (www.infoq.com/minibooks/enterprise-soa).
In particular on the technical side if your team buy into bounded contexts/context maps/UL/etcthen I think they'd find the transition to business focussed SOA relatively simple (though getting a good defintion of those business centric services would still be challenging).
In fact, to me, SOA is not a million miles away from the whole bounded context idea in DDD. If you wrap your bounded contexts in services and put those service names into the ubiqutous language then you are following a DDD centric approach and also creating business focussed services.
I still don't think that means SOA is DDD at a larger scale, I just think it means some of the patterns in DDD apply at the larger scale too.
SOA != CBD
SOA is an instance of a component based architecture.
In a component based architecture, there is not only a contract between the components and their consumers, but also between the components and the underlying runtime. This is (or shouldn't be IMO) the case for SOA.
Different perspectives, different types
a) technical - a service is a software component that reacts to a message
b) business - a service is a discrete business function that is performed in different context
c) architectural - a service is an element under a particular domain of control that can be assembled with other elements to constitue a solution to a particular problem
Then there are different types of elements, components... services: decision services, resource lifecycle services, computation services, real-world actuation services...
I am not sure why you say that SOA is not a component architecture, it fits pretty well your defition. I don't know many services that live outside of a container that otherwise offers a runtime contract to deal with things like transport independence, activation, security, reliability, monitoring... Even REST services live in a container, IMHO. Now it is true that a service transcent the container and a composite solution can be build with services that operate in different containers, but I think this is just because interoperability was an early concern of a couple vendors driving SOA standards, you can think of SOAs where interoperability is not a requirement. When you look at OSGi or SCA, interop takes quite a back seat there and you are still building SOAs but with a component model.
my 2 centimes,