Statement

Exceptions should be close to the class or interface that throw them.

Description

Sadly, dealing with exceptions in enterprise software systems is often an afterthought. But allocation of exceptions to modules has significant implications on the modularity, and more specifically the dependencies between modules, within our software system. Placing the exception close to a class that catches it will often cause a cyclic dependency between the module containing the class that throws the exception and the module containing the class that catches the exception. Exceptions should always be placed in a module closer to the class that throws the exception than a module closer to the class that catches the exception.

]]> http://www.kirkk.com/modularity/2009/12/colocate-exceptions/feed/ 0 http://www.kirkk.com/modularity/2009/12/container-independence/ http://www.kirkk.com/modularity/2009/12/container-independence/#comments Mon, 28 Dec 2009 19:28:50 +0000 kirk knoernschild http://www.kirkk.com/modularity/?p=355 For the full description, implementation variations, consequences, and detailed sample, see Page 150 in Java Application Architecture.

Statement

Modules should be independent of the runtime container.

Description

Modules with excessive runtime container dependencies are heavyweight modules that cannot execute outside the confines of the runtime container. Lightweight modules with no container dependencies have significant advantages.

Statement

Module relationships should be levelized.

Description

Levelized modules demand that module relationships be acyclic. Any cycles in module relationships therefore prevents levelization. To levelize modules relationships, there are several steps.

Statement

Modules should be as independently deployable as possible.

Description

For a module to be independently deployable, it cannot have any outgoing dependencies on any other module.

Statement

Module relationships must not violate logical layer relationships.

Description

It’s common knowledge that when designing systems of any degree of complexity, the presentation, business logic, and data access should be separated into distinct layers. There are several important considerations when separating the layers.

Statement

Module relationships should be uni-directional.

Description

When you define a relationship between two system modules, their coupling is increased. Some degree of  coupling is necessary simply because modules need to work together to accomplish some task. But certain types of coupling should be avoided. There are rules that will help you identify bi-directional relationships between modules.