I'm currently attending the DDD Europe conference in Amsterdam and thought it might be interesting for people at home to read up on some of the topics that this interesting (and well-organized) conference covers.

Mel Conway: Consider the development feedback loop

On Twitter there were outbursts of "The legend on stage" and "This is the Conway of 'Conway's Law'" when Mel Conway entered the stage. I knew about the law, which amounts to the observation that software systems tend to be shaped by the way the teams working on it communicate.

I had already tried to apply Conway's Law to the software products of the teams I've worked with in the past. Most certainly, it was an interesting exercise, one which has also led me to believe that we should be more pro-active about Conway's Law, which is actually more like a "Conway's Problem": we should fix it by shaping our teams and interactions in such a way that we can make better software. Something like this is already known as the "Reverse Conway's Law", by the way.

To be honest, my high expectations weren't met by the real talk. It felt somewhat irrelevant. There were some interesting ideas in it though:

• Sofware is becoming so important that everyone should have an idea of what's going on inside - it can't be all magic anymore.
• We need a better feedback loop for software development. We might be able to leverage the age-old feedback loop between hand, eye and brain.

An interesting corollary to the original law, introduced by Mel in his talk, is: stable interfaces allow groups to work together without having knowledge of each other's work. This is a highly relevant rule for teams working on the same overall system, with a need to get "unstuck". An example of this came from a demonstration of "visual programming with a Windows 3 Smalltalk application running on Windows XP in compatible mode inside a Virtual Machine on Mac" (I would have loved to see an entire talk on this by the way). Mel demonstrated how several larger components can be connected easily when the designer of the application defines several standardized interfaces through which different parts of the application connect.

Further reading: Mel's paper on simplifying the development process

Jérémie Chassaing: Thermodynamics of Software

The next talk I attended was an experimental talk (#NoSlides, and on short notice) by Jérémie Chassaing. I liked his style; I admire the kind of free form it had, something I haven't dared to try myself...

His talk built on the work of Carlo Pescio, mainly his ideas on the Physics of Software. Its endeavours are to discover and influence the forces that are working on software, either in the artifact space (the code, amongst other things) as well as the runtime space (the running application, amongst other things).

The notion of friction is interesting in this context. As is apparent in a lot of development teams, some aspects of a software product are easier to change than others. It can be easier to move the team in one direction, and harder to move in the opposite direction.

Several examples of friction in a DDD world: when you don't align your solution space (e.g. bounded context) with your user's problem space (e.g. subdomain), it will be hard to make your domain model follow along with changes in the domain that happen in the real world. The same goes for aggregates: if you get their boundaries "wrong", then they will work against you, making consistency hard to achieve, or giving you a false sense of consistency.

Friction can be leveraged too, when, for example, you don't want your team to move in a certain direction. For example, if you don't want to let your team change code without verifying that the unit tests still pass, let them install a pre-commit hook. I've applied this technique in my open source projects too. For example while designing the SimpleBus command bus library, I decided that command handlers wouldn't be allowed to have a return value. Not that it may never be useful to have a return value, I just wanted to make it really hard to rely in some way on the result of a "command" action.

Vaughn Vernon: The Language of Actors

Next up was a talk by Vaughn Vernon on the actor model. Having attended several other talks on this topic, it didn't bring me lot of new insights. The main idea is: actors are just like objects, except - when they call each other, the call is modelled as a message, which gets added to the queue of the other object, waiting to be processed in a non-blocking fashion. Again and again I must admit that I find this a fascinating concept. Asynchronous communication is the conceptual solution to a lot of real-world problems. Problems for which we currently have lots of shaky solutions in place, like synchronous (blocking) network calls, multi-threaded applications, database transactions, or centralized message brokers.

According to Vaughn, an actor system gives you a "simplicity stack", as opposed to the "complexity stack" many of us are currently working with (i.e. a layered architecture, with ports & adapters). I do "believe" in the actor model, I don't think it solves all of those problems though.

I'll take it from Vaughn that we should "embrace latency". We should be more and more ready for distributed work, across networks too. We should reduce the amount of state in our applications to a maximum level, mimicking a functional approach to modelling.

All of this will allow us to fulfill one of DDD's ideals too: to develop a Ubiquitous Language in a Bounded Context.

To be continued

I've had a great "first day" at DDD Europe. In another post I'll talk about several of the other talks I've attended. By the way, all the talks have been filmed and will be available online at some point.