NDepend

Improve your .NET code quality with NDepend

domain_driven_design_demystified

Domain-Driven Design Demystified

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_What_Is_It_and_How_Does_It_Work

Hexagonal Architecture: What Is It and How Does It Work?

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.

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. 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?

Software Architecture Document? You Don’t Need That

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…

Continue reading Software Architecture Document? You Don’t Need That