It’s all too common for developers to start coding an application
without a formal architecture in place. Without a clear and welldefined
architecture, most developers and architects will resort to
the de facto standard traditional layered architecture pattern (also
called the n-tier architecture), creating implicit layers by separating
source-code modules into packages. Unfortunately, what often
results from this practice is a collection of unorganized source-code
modules that lack clear roles, responsibilities, and relationships to
one another. This is commonly referred to as the big ball of mud
architecture anti-pattern.
Applications lacking a formal architecture are generally tightly coupled,
brittle, difficult to change, and without a clear vision or direction.
As a result, it is very difficult to determine the architectural
characteristics of the application without fully understanding the
inner-workings of every component and module in the system.
Basic questions about deployment and maintenance are hard to
answer: Does the architecture scale? What are the performance
characteristics of the application? How easily does the application
respond to change? What are the deployment characteristics of the
application? How responsive is the architecture?
Architecture patterns help define the basic characteristics and
behavior of an application. For example, some architecture patterns
naturally lend themselves toward highly scalable applications,
whereas other architecture patterns naturally lend themselves
toward applications that are highly agile. Knowing the characteristics,
strengths, and weaknesses of each architecture pattern is necesv
sary in order to choose the one that meets your specific business
needs and goals.
1