Domain-driven design, or DDD, is a software design methodology aimed at producing better software. Engineers achieve this by working closely with domain experts during the continuous design process.
Eric Evans created domain-driven design and wrote a book about the practice called Domain-Driven Design: Tackling Complexity in the Heart of Software. His main points are to use models, use the language of the business, and follow specific technical patterns during development. Together, these steps will help you deal with complex software without painting yourself into a corner.
In this post, I’ll go further into demystifying domain-driven design. First, I’ll share a story about how I came to know the practice myself. Then I’ll get into some details about the modeling part of the process. Finally, I’ll do an overview of the technical bits of the craft.
Continue reading Domain-Driven Design Demystified
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.
Interested in seeing what your codebase’s architecture looks like and whether it exists in the Zone of Pain?
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….
Continue reading Hexagonal Architecture: What Is It and How Does It Work?
There was a time when Linq was a mystery to me. But, now that I’ve learned how to use it, I don’t know how I ever lived without it! You’ll learn Linq with this complete beginner’s gentle introduction. All you need to know before you start is how to code a loop. Heck, I’ll even show you that first. Ready? Let’s get started!
Continue reading Linq Tutorial: A Complete Beginner’s Gentle Introduction
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?
Want to see living documentation of your software architecture, in vivid detail?
Download the NDepend trial for free and check out the powerful dependency graph feature to see what your architecture looks like.
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.
Continue reading Software Architecture Document? Do You Need One?