Weblogs Forum - A Layering Challenge

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
A Layering Challenge

21 replies on 2 pages. Most recent reply: Feb 11, 2005 12:06 PM by Jim Borynec

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 21 replies on 2 pages [ « | 1 2 ]

Kirk Knoernschild

Posts: 46
Nickname: kirkk
Registered: Feb, 2004

Re: A Layering Challenge

Posted: Feb 7, 2005 11:54 AM

>>I'm not sure what you mean by "promote".
>>HiveMind applications are broken into modules

I was wondering if that was the basic premise of HiveMind. Since modules are deployable units, it sounds like it is.

Dan Perl

Posts: 28
Nickname: nanov
Registered: Sep, 2004

Re: A Layering Challenge

Posted: Feb 7, 2005 4:17 PM

> I was wondering if that was the basic premise of HiveMind.
> Since modules are deployable units, it sounds like it is.

Please clarify what you mean by modules and by deployable units, because we haven't agreed yet that "modules are deployable units".

I think you are also mis-using the term of layering: "I do think we can all agree that applications should be layered". No, we don't agree. Layering and layered are not the same as modular. All the advantages you listed for layering are actually advantages of modular designs in general and layered is modular. But modular is not layered and all applications should be modular, but not all aplications should be layered.

As for the topic of modules/layers as deployment units I've already stated my opinion in your previous blog on this topic.

Kirk Knoernschild

Posts: 46
Nickname: kirkk
Registered: Feb, 2004

Re: A Layering Challenge

Posted: Feb 7, 2005 6:41 PM

>>Making business objects substantially different from your
>>database tables can lead to all sorts of grief (like
>>complicated SQL and slow performance) I try and avoid the
>>allure of Java's object modelling ability as I have to
>>squish it into a relational database anyways and it never
>>quite fits.

It sounds like you're letting your data drive the design of the application. I tend to let the behavior drive the design of the application. I usually find the mapping from the data structure to business objects fairly straightforward. The advantages of having a well-designed business object layer are what allows me to accommodate the new and unexpected behavior that comes along with changes in requirements and new discoveries.

>>As far as testing my business objects, yes you do need a
>>database because they are persistent objects but you need
>>it anyways and JUnit can handle setup and cleanup nicely.

But then you're dependent on the data never changing. If the data changes in unexpected ways, your tests begin to fail for no apparent reason. Decoupling your tests from the database allows you to test the behavior of your objects with the expected data set.

Kirk Knoernschild

Posts: 46
Nickname: kirkk
Registered: Feb, 2004

Re: A Layering Challenge

Posted: Feb 7, 2005 7:58 PM

>>Please clarify what you mean by modules and by deployable
>>units, because we haven't agreed yet that "modules are
>>deployable units".

I was using module in the HiveMind sense here, in response to a previous post. A module in the HiveMind sense is deployed as its own .jar file. A .jar file is a deployable unit.

>>I think you are also mis-using the term of layering: "I do
>>think we can all agree that applications should be
>>layered". No, we don't agree.

We may not agree that applications should be layered, but I'm not mis-using the term. I do feel that business applications with a graphical ui should be layered. I've also developed a lot of batch applications, and I feel these should be layered too.

>>Layering and layered are not the same as modular. All the
>>advantages you listed for layering are actually advantages
>>of modular designs in general and layered is modular. But
>>modular is not layered and all applications should be
>>modular, but not all aplications should be layered.

Agree with most of this. And if all applications should be modular, and we can agree that dependencies should be acyclic between modules, then layer your modules.

Regardless, the point of the original post is that if you have a layered application, then you should be able to separate your layers into separate deployable units with acyclic dependencies. If you can't, the application isn't layered. Agreed?

Dan Perl

Posts: 28
Nickname: nanov
Registered: Sep, 2004

Re: A Layering Challenge

Posted: Feb 7, 2005 10:28 PM

> And if all applications should be
> modular, and we can agree that dependencies should be
> acyclic between modules, then layer your modules.

I am not convinced that dependencies have to be acyclic between modules. That is true of packages (deployment units), as in the Acyclic Dependencies Principle (http://c2.com/cgi/wiki?AcyclicDependenciesPrinciple), but not necessarily modules in general. See for instance the "Counter Example Of Acyclic Dependencies Principle": http://c2.com/cgi/wiki?CounterExampleOfAcyclicDependenciesPrinciple

> Regardless, the point of the original post is that if you
> have a layered application, then you should be able to
> separate your layers into separate deployable units with
> acyclic dependencies. If you can't, the application isn't
> layered. Agreed?

Okay, layers do not have cyclic dependencies and modules that do (modules in the general sense, not the HiveMind sense) are not really layers. And because layers are cyclically independent then they can also be packaged and deployed separately. They don't have to but they can. I do agree with that.

But I think you are inferring much more in your original posting. It's not just "if you cannot deploy the layers separately, then you shouldn't call your application layered". You're also saying "and if your application is not layered, then its architecture is bad". And I don't agree with that. Layers are good but not every application has to or can be layered and applications can still be well architected without layering.

Please qualify your statements and do not justify them with just "we all agree on A, therefore you must agree on B". We haven't agreed on A and you have to justify A before using it as an argument for B. Why is cyclic dependency wrong inside a package? If two classes are cyclically dependent they cannot be deployed separately. So what? They can still be highly cohesive and strongly decoupled. Do you really need them deployed separately? The same can be extrapolated for application architectures. So you can still have a good architecture even if it's not layered and even if it cannot be broken into smaller packages. All the benefits you listed in the original posting are benefits of modular architectures in general and not just layered architectures.

I guess that this argument is turning into the ADP argument (see the links above) and obviously people disagree there too. So we will probably just have to agree to disagree.

Kirk Knoernschild

Posts: 46
Nickname: kirkk
Registered: Feb, 2004

Re: A Layering Challenge

Posted: Feb 8, 2005 5:07 AM

>>That is true of packages (deployment units), as in the
>>Acyclic Dependencies Principle
>>(http://c2.com/cgi/wiki?AcyclicDependenciesPrinciple), but
>>not necessarily modules in general. See for instance the
>>"Counter Example Of Acyclic Dependencies Principle": >>http://c2.com/cgi/wiki?CounterExampleOfAcyclicDependenciesPrinciple
I do most of my work in Java. In Java, a package is not your
typical deployable unit. A .jar file is. I believe ADP is more significant when applied to .jar files than it is to packages, unless the packages span .jar files. Cycles among packages is certainly undesirable. You should try to avoid cycles among classes, but it is not the primary concern.

>>You're also saying "and if your application is not
>>layered, then its architecture is bad"

Nope. I never said that. I stated that in many cases, where we think out applications are layered, they are in fact not layered. I did make an assumption that Layering is a common architectural pattern that most of us use most of the time.

>>Why is cyclic dependency wrong inside a package? If two
>>classes are cyclically dependent they cannot be deployed
>>separately. So what. If two classes are cyclically
>>dependent they cannot be deployed separately. So what?
>>They can still be highly cohesive and strongly decoupled.
Cyclic dependencies increase coupling. They create a maintenance burden. The limit reuse. They negatively impact testability. I don't see how any two .jar files, packages, or classes that have cyclic dependencies cannot be strongly decoupled.

>>So we will probably just have to agree to disagree.
That's ok too. I appreciate new perspectives. But I am interesting in how you decouple your code, increase testability, and ease maintenance. What patterns do you use?

Jim Borynec

Posts: 4
Nickname: jborynec
Registered: Feb, 2005

Re: A Layering Challenge

Posted: Feb 11, 2005 12:06 PM

> It sounds like you're letting your data drive the design
> of the application. I tend to let the behavior drive the
> design of the application.

This is a horrible mistake. Data lives much longer than applications. Data also extends beyond the application. In a very real sense, you what you do to the data is the essense of what the application does.

> >>As far as testing my business objects, yes you do need a
>
> >>database because they are persistent objects but you
> need
> >>it anyways and JUnit can handle setup and cleanup
> nicely.
>
> But then you're dependent on the data never changing. If
> the data changes in unexpected ways, your tests begin to
> fail for no apparent reason. Decoupling your tests from
> the database allows you to test the behavior of your
> objects with the expected data set.

However, the advantage of databases is that you can rollback. You do the test, get the answer and then roll back. This leaves the data unchanged. Lather rinse repeat as desired.

if the dataset ever does get changed, we have a class which reloads the test data set. Use this when making a new test database or after changing the database.

Flat View: This topic has 21 replies on 2 pages [ « | 1 2 ]

Previous Topic

Next Topic