Some of those things you listed are design methods and others are design architectures.
I think if methods really mattered that much, and if we had found an optimal one, we wouldn't see so much disagreement about them. Either methods don't matter or we don't have a good one yet -- we're all pre-Semmelweis/Lister doctors in the latter case.
Architecture certainly matters though. If you expect to swap out components often, then designing in components is important. If you expect to scale a particular layer of an application, then separating it into its own tier is important.
Personally I think that more data-driven or rules-driven architectures would be suited to many business systems, but there's a lot of vendor clutter and noise in that area.
-- Steve Huwig
> You received this message because you are subscribed to the Google Groups "Java Posse" group.
> To post to this group, send email to java...@googlegroups.com
> To unsubscribe from this group, send email to javaposse+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/javaposse?hl=en