Colin, I think that you are now saying that the pattern is useful, right? And althoug Erls books in your opinion doesn't focus enough on the business aspect of SOA that should not reduce the usability of this particular pattern, or am I mistaken?
/Herbjörn 2009/4/16 Colin Jack <[email protected]> > > > > But, you can have several layers of business meaningful services - > > all coarse grained in one way or another (e.g. focused on a process > > or some kind of information). And, if you only care about the > > biggest picture you are bound to run into a lot of trouble. > > I definitely care about these details, and usually someone in the business > will have some interest. > > However I'd question whether I'm getting bang for my buck by focussing the > discussion on these entity services. I think I'm better to view the Invoice > and the InvoiceHistory as both being part of a higher level service giving > me more context and more choices. > > The added context should improve the discussion (or thats my experience > with domain modelling) but it also frees me up, for example because my > design is now bounded within the business meaningful service I'd consider > the extra coupling involved in using a domain model more satisfactory. I'd > also now be happier to see the definition of the Invoice as only applying > within the context of that larger service, so I don't feel the need to come > up with a canonical data model style approach. > > My experience has been that tying the discussion down to a particular > context helps a lot and that focussing on the model/behavior/process is > easier if we don't jump immediately to small RPC serices. > > I'd also argue that when it comes to lower level services (individual > granular end-points) technical issues have to come into play, for example in > Erl's principles book he talks about Contract Denormalization and in > particular "...would result in unnecessary data exchange and excess > performance overhead for consumers that don't need the whole document". > > Thats obviously a good point, but each time we make this sort of choice > we're diluting the business meaning of the contract. I think thats fine, but > I also think its one reason that I don't necessarily view the contracts of > individual granular endpoints as being the best/only way of viewing the > system. > > I should also say that I've read two of Erl's books and really don't > remember there being that much focus on the business aspects of SOA, not > nearly as much as I was expecting and hoping for. > > > That sounds more like powerpoint, ivory tower architecture to me. > > Caring about architecture at a somewhat more detailed level does > > not mean that you do not care about the big picture - at least not > > in my world. > > I absolutely think the details matter and are worth discussing. What I do > think is regrettable is that these detailed levels seem to be the at the > expense of the larger SOA discussion. > > Colin > > > -- Med vänliga hälsningar Herbjörn Wilhelmsen
