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.
It’s been about a month since my last research post, and I’ve been musing about the next topic. What should it be? Well, I’ve decided. Since I love nothing more than throwing the gates wide for everyone’s internet anger, I thought I’d weigh in on the subject of self documenting code vs comments.
I’ll be awaiting your rage below, in the comments.
If you’re a .NET developer, then it’s overwhelmingly likely that you’re a Visual Studio user. There are alternatives to it, sure. But the product from the Redmond giant is the go-to when it comes to developing for the .NET framework.
For a newcomer, though, things can get confusing since Visual Studio isn’t a single thing.
Instead, it comes in several shapes and sizes.
Which one should you pick? What are the features that matter for your use case?
Since Visual Studio isn’t free—most editions aren’t, at least—you want to get the best bang for your buck.
That’s what this post is going to cover. As its title suggests, we’ll focus on the differences between the enterprise and professional editions of the integrated development environment (IDE).
By the end of the post, you’ll have learned enough to make an informed decision on which version of the IDE better suits your needs.
Download a free trial of NDepend and check out all of the architecture visualization you can get without needing to upgrade your VS edition.
Let’s get started.
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.