What do you think?
Rate this book
Software Architecture Patterns
It’s all too common for developers to start coding an application
without a formal architecture in place. Without a clear and well-defined 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 necessary in order to choose the one that meets your specific business
needs and goals.
As an architect, you must always justify your architecture decisions,
particularly when it comes to choosing a particular architecture pat‐
tern or approach. The goal of this report is to give you enough information to make and justify that decision.
without a formal architecture in place. Without a clear and well-defined 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 necessary in order to choose the one that meets your specific business
needs and goals.
As an architect, you must always justify your architecture decisions,
particularly when it comes to choosing a particular architecture pat‐
tern or approach. The goal of this report is to give you enough information to make and justify that decision.
Unknown Binding
4 people are currently reading
22 people want to read
About the author
Mark Richards
132 books13 followersLibrarian note: There are multiple authors with this name in this data base.
For the author of the UK's Funniest Dad Blog go to Mark Richards.
For the author of Software Architecture Patterns go to Mark Richards.
For the outdoor writer go to Mark Richards.
For the co-author of A Practical Approach to Conveyancing go to Mark Richards.
For the author of the UK's Funniest Dad Blog go to Mark Richards.
For the author of Software Architecture Patterns go to Mark Richards.
For the outdoor writer go to Mark Richards.
For the co-author of A Practical Approach to Conveyancing go to Mark Richards.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 of 1 review
December 5, 2023
Nice comparison of different architectural "styles": Layered, Microkernel, Event-driven, Microservices, and Space-based. These styles are compared on characteristics like scalability, fault tolerance and cost, and some basic considerations are given for each style, like the importance of a clear "bounded contexts" for microservices.
You probably don't need this report to figure out what style to use, plus most projects will end up with a mix of styles, but it can help you use terminology more precisely when documenting and talking about your system. Is your system "event-driven" or "message-driven"?
The one thing missing from this rather short report is an extensive list of resources for further reading.
You probably don't need this report to figure out what style to use, plus most projects will end up with a mix of styles, but it can help you use terminology more precisely when documenting and talking about your system. Is your system "event-driven" or "message-driven"?
The one thing missing from this rather short report is an extensive list of resources for further reading.
Displaying 1 of 1 review