In a previous post I discussed some of the talks I attended at the DDD Europe conference in Amsterdam. This conference has offered a lot more amazing content and I'd like to continue to tell you about it.
Lately I've been thinking about why Domain-Driven Design (DDD) has such a great attractive force on me. In particular when at the same time I'm strongly attracted by technology like Docker and its surrounding ecosystem of tools that are finally helping us to fulfill the ideal of continuous delivery, with relative ease. Configuring servers, deploying them, connecting them, etc. is what we previously would have called "operations" work. Now that developers themselves get to do more and more operations work, a movement was called to life: devops, where two previously separated responsibilities are merged into one: writing software and running it in production is part of the same, single task: shipping working software.
Domain-Driven Design shows a certain symmetry with the devops movement. DDD is to be considered a movement too. Aside from all the technical advice we get from it, which is the easiest to focus on for us developers, the main message is more like an encouragement, a call to action for the group of developers as a whole: immerse yourself in the business domain. Know the people and try to understand what their work is about. You don't need to be a domain expert yourself, but you need to talk to the people who are. Only then will you be able to create meaningful software, that isn't just great with respect to the technical aspects, but contributes to the success of the organization you've created it for. It should help them accomplish things they are not able to accomplish with a spreadsheet and a telephone alone.
Looking back at my own career as a software developer I can see that for many years my focus has solely been on technical excellence. I remember my girlfriend asking me several years ago: "But don't you care about the users of your software?" I answered: "No, as long as I can work on solving interesting technical problems!" This attitude is by far not sufficient, and learning about DDD has been a real wake-up call for me. Software development isn't about design patterns, or knowing all about your programming language or framework of choice. It's about delivering proven-to-work software that is meaningful to a group of people and helps them accomplish extraordinary things. I'm not saying you shouldn't learn all you can about the tools you're working with. It just shouldn't be your sole point of focus.
Nick Tune: Aligning Organisational & Technical Boundaries for Team Autonomy
Although I was aware that all the talks were being recorded, I usually get the most out of a conference by simply attending a talk and think it through. It's much less likely for this mental process to occur while I'm watching a talk at home, it just doesn't come with the same kind of special focus I have in a conference room, if I sit down to watch a video at all...
Another interesting talk I attended was one by Nick Tune, whose style of presentation I really love - and so did the entire audience I think. In previous talks I saw by Nick it became very clear that DDD is the perfect area for him to be operating in. As a developer he has a strong awareness of the business world surrounding him (us).
He started out with a call to action: to not wait for management to fix issues you recognize with a software system. Instead, we don't need to seperate between technical and management issues, since they are tied to each other and often amount to the same underlying problem. An important take-away from this talk to me was that instead of taking refuge in a chapter in "the blue book" or something, you should also consider more mundane solutions, like redistributing the work, relocating teams, or relieving the workload of a team in order to speed up partnerships between teams.
If you have some DDD background, you already know that DDD offers us the idea of a bounded context to help us separate our system into multiple different services, each with their own domain model. Finding the right boundaries for such a context is the hardest part of course. Accoring to Nick (quoting Udi Dahan), there are no rules for determining service boundaries. The main heuristic for determining the correct course though, is that every decision with regard to the boundaries should help the organization towards achieving its goal.
In practice, the best thing you can do is strive for autonomy. Hence Nick's suggestion to let go of "microservices" or "bounde
Truncated by Planet PHP, read more at the original (another 5010 bytes)