To me, the requirement of end-to-end services implementation is coming from applying the Service Orientation concept rather than from anywhere else: when creating a service, you cannot make one part of it service-oriented and another one not-SO. This is the principal difference of SO approach from DDD approach, which allows/recommends constructing domain objects and THEN 'making'(?) them service-oriented.
I believe, we can manage the coherence between SO and DDD using Domain Service-Oriented Modelling (DOSOM) and related design. That is, Service model goes first and defines the scope and boundaries if the domain objects. The 'Domain' part outlines the business-orientation nature of the service. I agree with Anne on the comment about "into the SOA" - Michael ________________________________ From: Anne Thomas Manes <[email protected]> To: [email protected] Sent: Wednesday, January 14, 2009 12:54:04 AM Subject: Re: [service-orientated-architecture] I say SOA was never born - How about now? Are WE ready? Gregg, While I agree with your recommendation to focus on "why", I recommend focusing on "what" way before you start thinking about "how". And you've totally lost me when you talk about moving end-to-end services "into the SOA". That terminology makes it sound like a SOA is a piece of infrastructure. (e.g., an ESB). Anne On 1/13/09, Gregg Wonderly <[email protected]> wrote: > Anne Thomas Manes wrote: >> >> >> On Mon, Jan 12, 2009 at 3:35 AM, Steve Jones <jones.steveg@ gmail.com >> <mailto:jones. steveg%40gmail. com>> wrote: >> > 2009/1/11 Anne Thomas Manes <atma...@gmail. com >> <mailto:atmanes% 40gmail.com> >: >> > >> >> Michael/Steve, >> >> >> >> If the definition of SOA is so simple and obvious, why is it that we >> >> get into heated permathreads whenever someone says something like "SOA >> >> = integration" ? >> > >> > Because that is the detail, which is where we are saying the issue is >> > but also because its part of the subversion that some analysts and >> > most vendors have done deliberately. SOA = Technology. >> >> But that's just my point: The industry has not agreed on the meaning of >> SOA. > > I'm not sure that there needs to a "meaning" as much as there needs to be > conveyed the "purpose" and the "results". Those two words, together, > describe > the "ideas" that provide the "meaning". > >> >> >> >> What are people talking about when they refer to "their SOA"? >> > >> > Their Service Oriented Architecture? Well most of the time its the >> > pictures and architectural artefacts that define how their IT is going >> > to be delivered, sometimes its the physical realisation of that >> > architecture and sometimes its just because they've bought a product >> > with an SOA sticker. >> >> When people talk about SOA as a thing, they are talking about their >> ESB. They might also include the applications that they've deployed >> that communicate using the ESB. They are not talking about pictures >> and architectural artifacts. > > When you make a statement like this, it feels loaded with personal > perspective > and generalizations that won't always be true. This is why I keep saying > that > the "why" (purpose of SOA) and "how" (technologies that produce the results > needed for YOUR SOA) need to be what is discussed, not the "what" > (technologies > that are often put in place as a solution looking for a problem). > > To put this in other words, we shouldn't say an SOA has web services, ESBs > and > browsers. Instead we should say "why" as in, you should develop an SOA to > help > you abstract points of extension into services that can be reused by layers > that > will develop around your core services. This provides a clean separation of > responsibilities and provides points of integration that can be used > throughout > the life cycle of your systems to augment, replace and extend them. > > Then we would say let's look at what your business has for end to end > services > now, and decide how we can compartmentalize and manage the movement of those > services into an SOA that will ease your business to make the changes that > it is > planning for the future. > > Gregg Wonderly > > Gregg Wonderly > > Gregg Wonderly >
