+1 on the principle vs. solution tradeoffs. I'm a big fan of establishing "this is the way it is done unless there is a reasonable reason not to." Of course the debate then turns to what's a reasonable exception and what isn't. :-)
Is there debate/disagreement on the merits of this principle? And touching on Mark Baker's response, how much completeness is the right amount? If the sender doesn't want to send why the prisoner is being held, that's cool. But then for recipients that need that information before taking some action, then the event is not complete in that context. The classic trade-off between too much info to wade through (message schemas run amok) vs. too little to be helpful (messages requiring several other queries). When do we recognize that a principle might be too idealistic, that adhering to its spirit will almost never be achieved in application? I'm not saying this principle falls into this category necessarily. Just wondering aloud... -Rob --- In [email protected], "jack541108" <[EMAIL PROTECTED]> wrote: > > --- In [email protected], "Steve Jones" > <jones.steveg@> wrote: > > > > A little bit pie in the sky here, nice in theory but a killer in > practice > > > > It's all about the difference between architectural principles and > solution architectures. Principles are guidance in ambiguous > situations toward an ideal. A solution architecture holds the > trade-off. Deviating from the principle must be motivated, adhere to > the principle not. That's what enterprise architecture is about. > > -Jack >
