Yes well I guess all things in balance. But I think in many cases people get off on the sort of complexity described here. Or at least prefer it as it means they spent less time percentage wise thinking about the actual problem at hand (which is far more boring ;)
I am just uber wary of this in the "java world" so to speak (seems to mainly be a problem there). I am sure in other tech (eg PHP) you would have the reverse problem. Of course the usual blah blah of "you can write good or bad code in anything" always applies (people shouldn't even have to say it out loud !). On Jul 30, 8:01 am, Casper Bang <[email protected]> wrote: > If you are on a large project with many technologies and people, over > a long period of time, the classic layered approach offers you the > best ROI. However, there's no doubt though that cross-cutting/fewer- > tier in general is gaining growth and has advantages too. I usually > like to think we use the layered approach only because its the best we > have while at the same time thinking we'll eventually solve that. Of > course Java in its current state is particular susceptible to the uber- > layering due to missing polyglot language features (lowest contract is > an interface, no dynamic types etc.). > > /Casper > > On 29 Jul., 23:29, Rakesh <[email protected]> wrote: > > > > > Stay with the 'classic' approach. > > > I've been on a couple of projects now where they avoided this approach > > (fuelled by having read Eric Evans book) and caused no end of > > problems. In the end, it was refactored to something resembling the > > layered approach anyway. > > > This anemic domain model anti-pattern is blown out of all proportion. > > Its a 'style' thing more than anything else as far as i can see. Most > > apps are essentially a web-front end to a database anyway and can be > > built quite successfully with an anemic domain model. > > > Its all about judgement. Domain objects for example contain business > > logic but this logic should only works against the attributes of the > > domain object. > > > Passing in services to the domain object is a step too far - the class > > needs loads more tests and violates Single Responsibility Principle > > (which after DRY, is the second most important principle). > > > So, stick with the classic approach until something better comes along > > - and sorry, but Eric Evans book is not it. Its a set of analysis > > ideas rather than implementation principles and even then he says use > > it for the most complex parts of your app. > > > No project failed because it used the layered approach. It failed > > because of inexperienced devs, poor requirements, impossible > > deadlines, etc. > > > R > > > On Wed, Jul 29, 2009 at 12:34 PM, Mwanji Ezana<[email protected]> wrote: > > > > On Jul 29, 12:40 pm, Michael Neale <[email protected]> wrote: > > >> No you are not - you are unfortunately perfectly sane and right to > > >> question this crazyness. I say unfortunately as you probably have > > >> overenthusastic colleagues that will drive your project into the > > >> weeds. > > > > Well, I'm really happy that today we came to a reasonable compromise. > > > A better world is possible! :) > > > > Moandji --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
