Service-oriented architecture (SOA) has been with us for a long time. The term first appeared in 1998, and since then it’s grown in popularity. It’s also branched into several variants, including microservice architecture. While microservices dominate the landscape, reports of SOA’s death have been greatly exaggerated. So, let’s go over what SOA is. We’ll cover why it’s an architectural pattern that isn’t going anywhere. Then we’ll see how you can apply its design concepts to your work. Continue reading Service Oriented Architecture: A Dead Simple Explanation
What’s the difference between a REST API and a RESTful one? Is there a difference? This sounds like the kind of academic question that belongs on Reddit. But then you find yourself in a design session, and the person across the table is raising their voice.
The short answer is that REST stands for Representational State Transfer. It’s an architectural pattern for creating web services. A RESTful service is one that implements that pattern.
The long answer starts with “sort of” and “it depends” and continues with more complete definitions.
A while back we discussed the unique career path architects have to travel. We wrote that article for developers who want to advance their careers and aren’t sure which way to go. Let’s revisit that path and talk about how you, as a manager or architect, can help developers along the way.
There’s a common misconception that’s permeated our profession: Architects don’t need to write code to do their jobs.
Now, this may seem like a harmless approach. After all, writing code is what developers do. And architects should be busy with more important tasks.
However, keeping architects from writing code can limit the potential of your development teams. It can also result in an architectural mess when requirements and business needs change.
So today let’s look at why giving your software architect time to write code is a good thing. But first, we’ll start off by looking at what life is like as an architect.
Hexagonal architecture is a model or pattern for designing software applications.
The idea behind it is to put inputs and outputs at the edges of your design. In doing so, you isolate the central logic (the core) of your application from outside concerns. Having inputs and outputs at the edge means you can swap out their handlers without changing the core code.
In this post, we’re going to take a look, in detail, at just how hexagonal architecture works. But first, let’s talk about why this is desirable.
One major appeal of using hexagonal architecture is that it makes your code easier to test. You can swap in fakes for testing, which makes the tests more stable.
Hexagonal architecture was a departure from layered architecture. It’s possible to use dependency injection and other techniques in layered architecture to enable testing. But there’s a key difference in the hexagonal model: The UI can be swapped out, too.
Download the NDepend trial for free and see if your actual architecture matches your design documents.
And this was the primary motivation for the creation of hexagonal architecture in the first place. There’s a bit of interesting trivia about its origins. The story goes a little like this….
So you’ve read about the Onion Architecture and think you get it. There are layers in this architecture. They’re onion-like. And they make your code better.
But how? And what do you put in each layer? And how the heck do you get your repository to be on the outermost layer of this onion?
Layered architecture gets a lot of flack.
Even though it’s still the most prevalent architecture, we view it as an anti-pattern. It’s old, not scaleable, and anti-SOLID. It encourages (shudder) monoliths!
The point is that even though it may not be an object-oriented nirvana, layered architecture is still a useful pattern. And if done right, it paves the way towards more advanced designs and architecture.
So let’s talk about layers.
In the spirit of the Agile Manifesto, we’ve reduced our dependence on software documentation. In some ways, this has improved our lives. And in other ways, it’s been taken too far and had the opposite effect.
The manifesto values “working software over comprehensive documentation,” which isn’t to say that documentation isn’t necessary. All too often, the baby is thrown out with the bathwater, and teams produce little to no documentation at all—including the software architecture document.
So which bits of documentation should we throw out and which should we still deliver? Indeed, we should prioritize those deliverables like any other user story. Some organizations will place a higher value on certain documents than others. Nearly all should put more priority on creating a software architecture document. Here’s why…
Design patterns seem to be a controversial topic. On one hand, many developers seem to love them and treat the famous book by the Gang of Four like sacred scripture. On the other hand, many developers loath the very idea of design patterns. It’s not too hard to find posts around the web with titles such as “Design Patterns are Bad Design,” “Following Design Patterns Is A Bad Idea,” and of course, the inevitable “Design Patterns Considered Harmful.”
What can we take from that? Well, as it is with pretty much everything in our industry, it’s really hard to reach some form of consensus on design patterns. My take is this: design patterns are tools. Some are more useful, others less useful. Some may be outright harmful. And others may not make sense for your scenario, but maybe for Joe who sits three desks from you, they’re a gift from heaven.
But that’s not what this post is really about (i.e. deciding whether design patterns are “good” or “bad”). As we’ve seen, such discussion is simplistic and misses the point.
What we’re going to do instead is cover three design patterns that haven’t aged quite well. These design patterns are ones that you no longer go around implementing. And if you do, you probably shouldn’t.
Let’s get started.
When I was attending night school to become a programmer, I learned several design patterns: singleton, repository, factory, builder, decorator, etc. Design patterns give us a proven solution to existing and recurring problems. What I didn’t learn was that a similar mechanism exists on a higher level in the form of the software architecture pattern.
These are patterns for the overall layout of your application or applications. They all have advantages and disadvantages. And they all address specific issues.
In this post, we’ll take a look at 5 such patterns in detail. For each software architecture pattern, this will include a description, its advantages, its disadvantages, and the situation for which it is ideal. The patterns are as follows.
- The Layered Architectural Pattern
- The Microkernel Architectural Pattern
- The CQRS Architectural Pattern
- The Event Sourcing Architectural Pattern
- The Microservices Architectural Pattern
Download the NDepend trial for free and use dependency graphs to get a feel for what your software architecture really looks like.