--- In [email protected], "Steve Jones" <[EMAIL PROTECTED]> wrote: > > I'd be a bit concerned if an application, plain or otherwise, wasn't > part of a business service. Part of the problem is that people > don't raise themselves above the technology because "they > understand its just going to the Phoenix Application". I've had > occasions where when you looked at it from the business perspective > and found that actually Phoenix shouldn't be the destination at all > but it had become the accepted wisdom of IT that it should.
We agree then that architectures should be service-oriented. But sometimes they are not. > At a architecture level it isn't important whether its event or not, > but at a design level its true that events aren't everywhere. I disagree. At the architecture level, events can be first class citizens, just as services are. There are plenty of business events to be identified and specified at the L1 level. > And on the later I'd disagree. I've never seen a decent business > architecture described from an event basis. If its T-SOA v EDA > then I agree, but if its B-SOA then I've just never seen an > equivalent B-EDA. I've never seen an architecture described only from an event basis, just as I've never seen an architecture described only from a service basis. There are usually other principles presented, though they are usually not explicitly called out because everyone is wrapped up around the SOA mania. > Again I think this is the difference between implementation and > architecture. Service Architecture as a principle lends itself, > from experience, to good EDA implementations. I guess we simply disagree to the level of were event-driven principles can be applied. Event-driven is not an implementation choice, IMO. > Bloody hell my ground state really is grumpy... Completely understood. Your posts are no grumpier than usual. :) -Rob
