--- In [email protected], "Rob Eamon" <[EMAIL PROTECTED]> wrote: > > --- In [email protected], "Kirstan > Vandersluis" <kirstan@> wrote: > > > > I am beginning to see where you and I divert. I suggested in > > another post to Steve that using his service decomposition > > strategy from his book, you would eventually recognize a set of > > these entity-style services. He then called them "support > > services" that would be governed by higher level services. Is that > > what you mean by "CRUD components being used for service > > implementation"? > > Yes, this matches what I was thinking. > > > And these would fall outside your definition of a service? > > Well it brings into question what do we call a "service?" If we have > layers of services, which seems a natural decomposition strategy, we > have to ask how useful is it for lower layers to be discoverable. How > reusable will they really be? Are lower level services to be used > only by services in the next tier above? If not, then how will the > complexity be managed? If so, how do we manage the restriction? Does > calling all the components in the multiple layers "services" > introduce confusion or clarity? >
Great questions to ponder. I personally feel there is so much literature acknowledging these lower level components as "services", it will be impossible to name them otherwise. I think it makes more sense to qualify them, e.g. "private service" for one not intended to be exposed outside its parent tier. -Kirstan
