1. Domain-Driven Design: time for a case study

    Today I’m going to make good on my promise: we will finally apply the concepts of Domain-Driven Design to a piece of source code. I’ve developed a fictional case study that I hope to be both, simple enough to understand, but also realistic enough to be useful.Read article

  2. Domain-Driven Design: is my design any good?

    There are many ways to design a system. Some are more fit for purpose than others. If your team spans different roles, your design should facilitate teamwork. In this article, we’ll learn about a technique to evaluate that particular aspect of your design.

    Read article

  3. Domain-Driven Design: five ways to facilitate change

    Domain-Driven Design asks us to experiment with the words and concepts we use in our models. Each change must be consistently applied across all artifacts though. Otherwise, our systems will become tough to understand. Keeping our artifacts up to date is a lot of work, but there are ways to reduce the burden.Read article

  4. Domain-Driven Design: refinement

    Model refinement is an important part of Domain-Driven Design. Although this sounds easy at first, it turns out there is a tension between model refinement and ubiquitous language.

    Read article

  5. Domain-Driven Design: the limits of ubiquity

    In discussing the benefits of a shared mental model we always did so in the context of a team. But many organisations consist of more than one team. Can we take the ideas of Domain-Driven Design and apply them to an entire department or even the whole company?Read article

  6. Domain-Driven Design is first and foremost about teamwork

    About eight years ago, I came across the concept of Domain-Driven Design (DDD) for the first time. Back then, I was still working in a tiny startup with only a handful of developers. And although I did learn about entities, aggregates and the like back then, I completely failed to understand that DDD really is about teamwork.Read article

  7. Going across and beyond

    I realized that one of my favorite work-related stories from last year is worth sharing on this blog, because there is such a powerful lesson in there. It’s a great example of how useful it can be if you take a step back and look at the larger picture. I’m quite sure that you’re going to enjoy it.

    Read article

  8. Guiding principles for a thriving remote team

    The one thing that gets me out of bed in the morning is a chance to help those around me to accomplish great things. So when I found myself in a struggling remote team I couldn’t resist the opportunity to make improvements. This article outlines the principles that guided me along the way.

    Read article

  9. Seven ways to explore the power of pair programming

    For the majority of my career as a programmer I believed that I was way more productive when working solo. Had you been on my team back then, you would have found me almost exclusively wearing noise cancelling headphones, in a deep state of focus, trying to turn out lots of high quality code.Read article

  10. Together we code?

    This is a website about working together. We’ve got a whole bunch of topics to cover, spanning pretty much all aspects of software development. Occasionally, we’ll be venturing out into related topics such as change management, mentoring, and good old-fashioned trust.Read article