+1 and the important thing to remember about _data_ access is that as soon as you have to assume state you are implicitly coupling systems. If two services/systems can't view the data without knowing it is at "stage X" in service/system B then those two systems are coupled to the business logic in B.
Steve 2008/7/21 Rob Eamon <[EMAIL PROTECTED]>: > --- In [email protected], Michael > > Poulin <[EMAIL PROTECTED]> wrote: >> >> <<What's often overlooked among these layers are the schemas. Many >> service designers allow schemas to become skewed in support of the >> service layer, but there is a real opportunity to build a data >> architecture that is fully capable of facilitating individual >> services (usually through shared schemas) but can also be used >> outside of the service layer by other parts of the enterprise that >> can benefit from its usually uniform, abstracted view of enterprise- >> wide data.>> >> >> +1 >> >> Data model/schema in a data store may be a business data model. >> Services do not need to use the entire business data model but its >> sub-models/sub-schemas/views. Those certainly may be reused outside >> of services. DAL is the example of this approach. > > +1. > > Random thoughts that this post triggered: > > * It's BA or EA that we should worry about, not SOA. SOA is not a > discrete level of architecture, it's a style. Apply SO, where it > makes sense, but a BA/EA needs to address more than just SO--such as > where DAL may fit in, or how the various data models are to be > leveraged. > > * DAL might be leveraged by an SO system, but DAL is not related to > SO. A DAL is data oriented. Service wrappers around data access is > still data oriented. > > -Rob > >
