Well it's not always optimal for higher levels to be directly dependent on lower layers but the higher level modules should instead depend on abstractions defined by interfaces/services defined in a mediator module. The interfaces services is then implementended
in terms of a lower level interface. This breaks the direct dependency between the higher level. The problem with a traditional approach is that dependencies is transitive and a change in the lower layer "leaks" and affects all the layers upwards. This can
of course happen anyway often as requirements change but thats kind of ineviteble. Having the middle man interface gives some increased complexity but often makes the architecture more losely coupled and makes it easier to make modules pluggable in the architecture.
This is also known as the dependency inversion principle (Google for it and you will find a lot of references. But basically this is kind of a service oriented architecture within your architecture. I think often we are to bound by strict layering and forget
some basic principles to reduce dependencies and quite often mix specifics with abstractions. /Michel
Michel, I agree with what you say but I think that these aspects don't start to become /that/ important until the project is becoming moderately large...for many smaller projects (with just two or three developers, say) it's often practical to allow direct
access to lower layers...of course, adding interfaces for this access to the layer directly below instead doesn't hurt, but it is sometimes overkill. /Mats
Another aspect is that when the layers start to become so large and complicated that the "leak" effect could become a serious problem, in my view this means it is time to start slicing the whole stack of layers in the tier up vertically and splitting the functionality
into distinct services. /Mats
I agree with you partially. But more often than not projects start out small and become large, so taking small amounts of caution in the beginning of the project both the make interfaces and do some amount of vertical splitting within the solution makes the
testing work so much easier, because you can write mockup services not directly interacting with physical storage e.g. And the early logical vertical splitting enhances understanding and readability of the solution. And from a deployment perspective even doing
vertical splitting in assemblys modules that contains all layers in one module for the particular functionality makes sense since many changes go through one vertical and can make deployement easiers. But I'm have several times taken over outgrown architectures
and seeing the slow growth of small applications to large and largely because of different constraints and knowledge of average developers has made refactoring lagging behind. Nice weekend (Trevlig Helg) /Michel
Michel, In the end, I have to agree with you. Your point is better and more worth to listen to. I was going to go "refactoring, refactoring" but you anticipated this move and pointed out that good refactoring practices just isn't always a reality in every project.
So, while I still maintain my point about vertical layers, and that the domain layer can be one such layer (I don't think you argued against that?) I'm going to have to end up agreeing with you that what I recommend can be quite a risk for a project that may
grow...the only counter-argument I have is based on assuming that refactoring is part of the everyday development. In /such/ a case, I think that "going overboard" with the abstractions and the layer isolation from day one can be a case of "trying to predict
the future" (becuase you can't really know in advance /which/ isolations, exactly, that are actually going to be useful as the project grows) and that it is better to refactor in the direction you suggest, as the project grows. But take this situation: You
want to hack up some db-driven news, an event calender, a guestbook and a forum for a company's web site. About a one-week job, perhaps. I've seen plenty of these projects turn into /three/-week jobs instead just because slavish adherence to layer isolation
was followed. And that's just unpractical, if you ask me. Nice weekend to you too! (Trevlig Helg du med) (Note to non-swedes: we're just wishing each other a nice weekend in Swedish - we're not calling the forum mods names in our bizzare language ;-) /Mats
>So, while I still maintain my point about vertical layers, and that the domain layer can be one >such layer (I don't think you argued against that?) I'm going to have to end up agreeing with >you that what I recommend can be quite a risk for a project that
may grow...the only >counter-argument I have is based on assuming that refactoring is part of the everyday >development. In /such/ a case, I think that "going overboard" with the abstractions and the layer >isolation from day one can be a case of "trying to
predict the future" (becuase you can't really >know in advance /which/ isolations, exactly, that are actually going to be useful as the project >grows) and that it is better to refactor in the direction you suggest, as the project grows. I think we agree on
vertical layers. My main point was that it makes often makes more sense from a dependency point to do the physical layering at the vertical i.e front-end controller, domain model, data access in the same assembly for a particular vertical. Instead of the usual
physic all layering in horisontals keeping the dataaccess, domain, and controller/services/facade apart. This solution makes for heavier deployment even if only one vertical has changed (i.e order managment). But maybe we have different views of what vertical
and horisontal layering is. I don't agree it is going "overboard" to do abstractions from and shielding of layers from day one just keep the interface light and not to much functionality. And yes refactoring should be a day of everyday development, as should
unit testing, nightly builds, smoke tests. But a lot of shops don't see value in those practices unfortunately. And I very seldom see major architectural rewrites/refactoring of working systems in production, because the team don't wan't to break anything
and distrust unit testing and qa. Usually testing also goes down for a corporate system after the inital release and this makes teams vary to do changes. And if major rewrites is done it's under extreme pressure since the original solution didn't scale and
the roof has been hit in terms of users and transactions. This is the reality that I'm fighting and working to change and in these environments a little more design up front pays up as I see it. Don't get me wrong, I think this is quite fun because there is
often lot of rooms for improvement and learning in these kinds of shops. >But take this situation: You want to hack up some db-driven news, an event calender, a >guestbook and a forum for a company's web site. About a one-week job, perhaps. I've seen >plenty
of these projects turn into /three/-week jobs instead just because slavish adherence to >layer isolation was followed. And that's just unpractical, if you ask me. Yes I agree as long as all participants from the bottom top the top in the organization agrees
on what kind of solution the have bought into in one week. But for me at least it has happened several times that managment and salespeople go a head and promise a solution based on the nice facade you have hacked up in one week (or even weekend) to solve
some short term requirement. But much of the work is about lowering expectations and make them reaalistic to the users and managment. Or the solution is handed over to some junior "learning" architecture and design by copying and pasting that this is the way
it should be developing systems. Regards (and also a nice weekend to the rest of you participants in this forum ;)) /Michel
"I think we agree on vertical layers. My main point was that it makes often makes more sense from a dependency point to do the physical layering at the vertical i.e front-end controller, domain model, data access in the same assembly for a particular vertical.
" Interesting! Yes, we agree, but I'll admit I hadn't gone so far (in my thoughts) as to put the vertical /slice/ of the layer-stack into one /assembly/ as you suggest...but I have to say I like it! It really brings home the point of how SOA meets Layered
Architecture! I think this it is very possible my future designs will start drifting in this direction... ..and of course, each such "sliced-up" assembly should have access to any of the actual vertical layers...yes? /Mats
>Interesting! Yes, we agree, but I'll admit I hadn't gone so far (in my thoughts) as to put the >vertical /slice/ of the layer-stack into one /assembly/ as you suggest...but I have to say I >like it! It really brings home the point of how SOA meets Layered
Architecture! It's kind of SOA in the small or within a system to use the current buzzwords ;). >I think this it >is very possible my future designs will start drifting in this direction... Great, I hope it pays off. But I really find it interesting thinking
about physical and logical dependencys and try to slice the system up in a way that make me able to change one part of functionality without having to redeploy/retest the whole solution. >..and of course, each such "sliced-up" assembly should have access to
any of the actual >vertical layers...yes? Yes within reason. Apply the usual caveats of good design, and not creating a dependency mess. Depending on the complexity of the external services needed for a vertical, a mediatior or applying the dependency inversion
principle could help alleviate some of the problems. And also in some cases the cost of duplicating some code (especially in the lower end of complexity) might be lower and more sensible than introducing a dependency. Coupled with a good refactoring process
of course. /Michel
michel_andre
Member
410 Points
82 Posts
Re: Best Architecture
Oct 15, 2004 10:06 PM|LINK
matshelander
Member
235 Points
47 Posts
Re: Best Architecture
Oct 16, 2004 12:13 AM|LINK
http://www.npersist.com - free open source O/R Mapper for .NET
http://www.objectmapper.com - GUI O/R Editor supporting NPersist, NHibernate, ECO II
matshelander
Member
235 Points
47 Posts
Re: Best Architecture
Oct 16, 2004 12:15 AM|LINK
http://www.npersist.com - free open source O/R Mapper for .NET
http://www.objectmapper.com - GUI O/R Editor supporting NPersist, NHibernate, ECO II
michel_andre
Member
410 Points
82 Posts
Re: Best Architecture
Oct 16, 2004 07:26 AM|LINK
matshelander
Member
235 Points
47 Posts
Re: Best Architecture
Oct 16, 2004 12:51 PM|LINK
http://www.npersist.com - free open source O/R Mapper for .NET
http://www.objectmapper.com - GUI O/R Editor supporting NPersist, NHibernate, ECO II
michel_andre
Member
410 Points
82 Posts
Re: Best Architecture
Oct 16, 2004 05:36 PM|LINK
matshelander
Member
235 Points
47 Posts
Re: Best Architecture
Oct 17, 2004 02:01 AM|LINK
http://www.npersist.com - free open source O/R Mapper for .NET
http://www.objectmapper.com - GUI O/R Editor supporting NPersist, NHibernate, ECO II
michel_andre
Member
410 Points
82 Posts
Re: Best Architecture
Oct 18, 2004 08:53 AM|LINK