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!

Yes, I know. Hexagonal architecture is the way to go. Or maybe I’m feeling a taste for onions. But only if it’s clean!

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.

Continue reading Layered Architecture: Still a Solid Approach

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.

In this post, we’ll take a look at the balance of these concerns in relation to a software architecture document.  What is this, and when do you need it?

Understanding the Need for Balance

The Agile 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…

Continue reading Software Architecture Document? Do You Need One?

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.

Continue reading 3 Design Patterns That Have Aged Poorly

From posts that politely offer their criticisms to others that outright deem them “for dummies,” it seems that bashing the SOLID principles is all the rage nowadays.

The fact that SOLID is being criticized isn’t a bad thing. The problem is that I don’t think the arguments against it are really that good. There’s some valid criticism, but it seems that a large portion of it comes from some misunderstanding of the principles. Some people even read obscure agendas in them.

This post is meant to investigate some of the more common criticisms of the SOLID principles, offering my take on why I believe they’re not quite justified.

SOLID Principles: Some Background

In object-oriented design, the SOLID principles (or simply SOLID) are a group of five design principles meant to make code cleaner, more flexible, and easier to change. The principles were compiled by Robert C. Martin, although he didn’t invent them. In fact, these specific principles are a subset of many principles Martin has been promoting over the years.

The name SOLID is an acronym, made up of the names of five principles. Namely, these principles are

• the single responsibility principle (SRP),
• the open-closed principle (OCP),
• the Liskov substitution principle (LSP),
• the interface segregation principle (ISP), and
• the dependency inversion principle (DIP).

Martin himself didn’t come up with the acronym; rather, it was Michael Feathers that suggested it to him, several years after he was already teaching them. I’ll come back to this later because, believe it or not, the name itself is at the center of some criticisms.

Before we get to the meat of the article, I think it’d make sense to do a quick overview of the five principles so those of you who are familiar with them can get a reminder and those who aren’t can get a sense of what we’re talking about.

Continue reading In Defense of the SOLID Principles

It’s time for the second part of our series about clean architecture. As promised in the first post, we’re going to show you a sample application in C#, to demonstrate what a clean architecture implementation might look like.

Even though our sample application will be minimalist, it’s still too much for a single post. We want to keep things light and easy for you, so we’ll have to break this post into two or three parts.

Don’t worry though: at the end, I’ll connect all the dots and things should (hopefully) make sense. And all the generated code will be publicly available for you to download and study on your own.

Continue reading Starting A Clean Architecture Example in C#