Ninja Ferret

The random thoughts of a software developer

DDD North 2020

Once again, I had a great time at DDD North, thank you to all of the organisers and sponsors who made the event happen.

Friday/Saturday night

One of the things I love about the DDD community is getting to meet up with old friends and making new ones. I always travel to one of the events on a Friday afternoon and return home on a Sunday, partly because it can be a long way to travel, but mostly because it gives me a chance to attend the social events.

Friday night, a group of us got together and decided to head out for a curry. Saturday night, Phil Pursglove created an eventbrite sign-up and booked a table at Pizza Express, sadly, he could not make it but I want to thank him for organising it and to say that we had a good time in his absence.

I met some new people and talked to friends I've known for years through the community. We chatted on topics from Blazor to public speaking to anything else that popped into our heads. I can learn as much from evenings like this as I can from the conference, I can get to talk to the speakers, and the other delegates. I learned that the translation of the Japanese for Sunday is "sun day", we talked about how language works, or doesn't, we talked about coding, we just laughed and had fun.

I want to make sure that people know these events are happening, that we are not just a cliquey group, we will welcome newcomers to our fold (we're not that scary).

A Monolith of Microservices

I was lucky enough to be selected to speak and give my talk A Monolith of Microservices. I was surprised at how many people turned up, with people sitting on the stairs and standing at the back, though I've given it before I was a bit nervous so finished a bit earlier than I had planned but that gave space for some really good questions.

You can find my slides from the talk here.

One of the questions that arose was "Can you really deploy a monolith as fast as microservices? Especially when you are promoting them through different environments." This suggested to me that:

  • There was not continuous delivery (though maybe automated deployment)
  • Humans were involved in making the decision to promote to a new environment

My belief is that such an organisation is not ready for a microservice approach, they have a monolithic mindset where changes have to be batched together, deployed to an environment and approved by a human. As organisations mature and adapt to the new world, they have to codify and automate their policies; the continuous delivery pipeline (not a human) is making the judgements about what can and cannot deploy and that humans control this by changing the policies.

I still believe that the Monolith of Microservices is a good architectural pattern for them, as they mature it will allow them greater flexibility.

.NET configuration is easy... right?

Sketchnotes from the talk '.NET configuration is easy... right?' by Steve Collins

Steve talked us through the different options that exist for configuring .NET applications, starting from the deep history of .ini files moving through to the modern era of secret vaults.

In the early days of .NET, there was only one way to configure an application and this was accessed through a static singleton object (untestable and not extensible). Steve showed how we can combine multiple different sources to configure an application and how the new frameworks have become more testable.

An introduction to domain-driven design

Sketchnotes from the talk 'An introduction to Domain-Driven Design?' by Craig Phillips

Craig introduces us to the core concepts of Domain-Driven Design, how modelling the real world and aligning our code to that model will help minimise the friction between the developers and the business.

I liked how Craig introduced the concept that the modelling exercise is not a one-off task at the start, it is a continuous discussion between the stakeholders and the development team, the ubiquitous language that is developed can be constantly evolving and this means that the code will constantly change to reflect this. This is not "big up front design".

Kubernetes on Raspberry Pi

Sketchnotes from the talk 'Kubernetes on Raspberry Pi' by Chris Wraith

Chris gave us a brief introduction to the history of the Raspberry Pi, and of Kubernetes. He had brought with him a network of Raspberry Pis, one master and three nodes, and showed us how he could deploy images quickly. He showed us how we could quickly we could scale a solution with a few commands.

I haven't played much with either a Raspberry Pi or Kubernetes but I can see how this can be an interesting way to provide developers with a small, affordable Kubernetes cluster for testing.


blog comments powered by Disqus