>From my last conversation with Eric Evans, I did not get an impression that >business service and context in DDD are the same. In DOSOM, business service >defines the scope, not the context, of domain object modelling, leaving the >execution context outside of the service. This allows reuse of the service in >different execution contexts.
One of the major differences between service-oriented and application-oriented design and implementation is in that services do not own the contexts they are used in; they, actually, do not know who and where uses them (this relates to both autonomous and composite services). The business application in SO is a composition of services or a hierarchy of compositions. Applications, in the contrast, tend to own and manage everything they depend at run-time (this has produced an ownership mentality in IT Management inherited from 80s when people thought they could have a life-time job and built life-time applications not suitable for constant changes). IMO, implementing services requires modification of this ownership mentality because service owner has quite narrowed ownership/responsibility but significantly extended accountability in comparison to application-oriented development. As of the data management part, I can only rephrase what I said: service process data given to it if the data fit into the business data meta-model owned by the service; service does not manages data it processes - there should be another entity concerned about this because data management is not a part of business function as well as data storages, data feeds, and data sources. - Michael ________________________________ From: Colin Jack <[email protected]> To: [email protected] Sent: Friday, April 17, 2009 10:03:32 PM Subject: [service-orientated-architecture] Re: Joe on Microsoft's combination of SOA & Storage > If your EC changes, you cannot guarantee service SLA and, > sometimes, service behavior and results. Well I'm definitely coming at all of this from a DDD mindset and (as you know) in DDD you have bounded contexts each of which can own their own models/database schemas etc. Ultimately there might be one database shared by multiple bounded contexts (simple cases), or different databases, or different databasse on different servers. In fact to me giving a bounded context (or business service) control of its own environment, including how the data is managed, is useful from the SLA perspective (and general autonomy). I'm not saying its necessarily part of SOA, but I think of it as a useful part of the implementation of services. > Ownership of resources is typical application- oriented approach: > applications try to occupy and own all possible entities they > depend on at run-time. Service-oriented approach is based on > separation of concerns and responsibilities placed on the top of > competition in QoS. Tell me that I am wrong. Can't tell you that, I don't entirely follow though. I guess I don't fully understand what you mean by "you should never MANAGE data you service works with, you have to process/massage/ transform the data, not manage, and by no means - manage data store.".
