Software Architecture Patterns in a nutshell
Mark Richards is a Boston-based software architect who’s been thinking for more than 30 years about how data should flow through software. His book, Software Architecture Patterns, focuses on five architectures that are commonly used to organize software systems. The best way to plan new programs is to study them and understand their strengths and weaknesses.
1) Layered (n-tier) Architecture
2 ) Event-Driven Architecture
3) Microkernel Architecture
4 ) Microservices Architecture
5 ) Space-Based Architecture
- Layered (n-tier) Architecture: This approach is probably the most common because it is usually built around the database, and many applications in business naturally lend themselves to storing information in tables. Many of the biggest and best software frameworks — like Java EE, Drupal, and Express — were built with this structure in mind, so many of the applications built with them naturally come out in a layered architecture.
The code is arranged so the data enters the top layer and works its way down each layer until it reaches the bottom, which is usually a database. Along the way, each layer has a specific task, like checking the data for consistency or reformatting the values to keep them consistent. It’s common for different programmers to work independently on different layers.
- Event-Driven Architecture: Many programs spend most of their time waiting for something to happen. This is especially true for computers that work directly with humans, but it’s also common in areas like networks. Sometimes there’s data that needs processing, and other times there isn’t. The event-driven architecture helps manage this by building a central unit that accepts all data and then delegates it to the separate modules that handle the particular type. This handoff is said to generate an “event,” and it is delegated to the code assigned to that type. Programming a web page with JavaScript involves writing the small modules that react to events like mouse clicks or keystrokes.
The browser itself orchestrates all of the input and makes sure that only the right code sees the right events. Many different types of events are common in the browser, but the modules interact only with the events that concern them. This is very different from the layered architecture where all data will typically pass through all layers.
- Microkernel Architecture: Many applications have a core set of operations that are used again and again in different patterns that depend upon the data and the task at hand. The popular development tool Eclipse, for instance, will open files, annotate them, edit them, and start up background processors. The tool is famous for doing all of these jobs with Java code and then, when a button is pushed, compiling the code and running it. In this case, the basic routines for displaying a file and editing it are part of the microkernel. The Java compiler is just an extra part that’s bolted on to support the basic features in the microkernel.
Other programmers have extended Eclipse to develop code for other languages with other compilers. Many don’t even use the Java compiler, but they all use the same basic routines for editing and annotating files. The extra features that are layered on top are often called plug-ins. Many call this extensible approach a plug-in architecture instead. Richards likes to explain this with an example from the insurance business: “Claims processing is necessarily complex, but the actual steps are not. What makes it complex are all of the rules.” The solution is to push some basic tasks — like asking for a name or checking on payment — into the microkernel. The different business units can then write plug-ins for the different types of claims by knitting together the rules with calls to the basic functions in the kernel.
- Microservices Architecture: Software can be like a baby elephant: It is cute and fun when it’s little, but once it gets big, it is difficult to steer and resistant to change. The microservice architecture is designed to help developers avoid letting their babies grow up to be unwieldy, monolithic, and inflexible. Instead of building one big program, the goal is to create a number of different tiny programs and then create a new little program every time someone wants to add a new feature.
Moral strength of Microservices Architecture
- There is a team of developers working on the application
- New team members must quickly become productive
- The application must be easy to understand and modify
- You want to practice continuous deployment of the application
- You must run multiple copies of the application on multiple machines in order to satisfy scalability and availability requirements
- You want to take advantage of emerging technologies (frameworks, programming languages, etc)
- Space-Based Architecture: Many websites are built around a database, and they function well as long as the database is able to keep up with the load. But when usage peaks, and the database can’t keep up with the constant challenge of writing a log of the transactions, the entire website fails.
The space-based architecture is designed to avoid functional collapse under high load by splitting up both the processing and the storage between multiple servers. The data is spread out across the nodes just like the responsibility for servicing calls. Some architects use the more amorphous term “cloud architecture.” The name “space-based” refers to the “tuple space” of the users, which is cut up to partition the work between the nodes. “It’s all in-memory objects,” says Richards. “The space-based architecture supports things that have unpredictable spikes by eliminating the database.” Storing the information in RAM makes many jobs much faster, and spreading out the storage with the processing can simplify many basic tasks. But the distributed architecture can make some types of analysis more complex. Computations that must be spread out across the entire data set — like finding an average or doing a statistical analysis — must be split up into subjobs, spread out across all of the nodes, and then aggregated when it’s done.
Software Architecture Vs. Software Design
Software architecture exposes the structure of a system while hiding the implementation details. Architecture also focuses on how the elements and components within a system interact with one other. Software design delves deeper into the implementation details of the system. Design concerns include the selection of data structures and algorithms, or the implementation details of individual components.
Architecture and design concerns often overlap. Rather than use hard and fast rules to distinguish between architecture and design, it makes sense to combine them. In some cases, decisions are clearly more architectural in nature. In other cases, decisions focus heavily on design and how it helps to realize that architecture.
An important detail to note is that architecture is design, but not all design is architectural. In practice, the architect is the one who draws the line between software architecture (architectural design) and detailed design (non-architectural design). There are no rules or guidelines that fit all cases — although, there have been attempts to formalize the distinction. Current trends in software architecture assume that the design evolves over time and that a software architect cannot know everything up front to fully architect a system. The design generally evolves during the implementation stages of the system. The software architect continuously learns and tests the design against real world requirements.
Impediments to Achieving Architectural Success
- Lack of adequate architectural talent and/or experience
- Insufficient time spent on architectural design and analysis
- Failure to identify the quality drivers and design for them
- Failure to properly document and communicate the architecture
- Failure to evaluate the architecture beyond the mandatory government review
- Failure to understand that standards are not a substitute for a software architecture
- Failure to ensure that the architecture directs the implementation
- Failure to evolve the architecture and maintain documentation that is current
- Failure to understand that a software architecture does not come free with COTS or with the C4ISR Framework
Thanks for reading. I wish you have a happy reading.
Note:- I have took an Effort to summarise from link given above .
