Mr Vaughn Vernon is a software developer and architect with more than 35 years of experience in a broad range of business domains. He is, also, a leading expert in Domain-driven Design. His books have been influencing developers all around the world.

In this post, we share a very short interview with Mr Vernon where he gently shares his thoughts about the current state of Domain-driven Design and software development.

We want to express our gratitude to Mr Vernon for kindly taking the time to answer our questions.

Question #1 – What is the current relevance of DDD and how is it going with adoption?

Mr Vernon – My viewpoint is that DDD is more relevant than ever and its adoption is growing. DDD is more than 15 years old, which means it is far beyond any potential hype cycle. The reason it continues to be relevant is that architects and developers are extremely tired of being burned by random architecture and implementation decisions. The past failures with software have proven that effective architecture and design are not achieved effortlessly, as if it will all just work out well.

Question #2 – Do you recommend a “learning path” for those who are starting to learn about DDD today?

Mr Vernon – The most important path is to use DDD in projects. Yet, many have found this very challenging because it is a different way of thinking.

I have written two books about DDD, “Implementing Domain-Driven Design” and “Domain-Driven Design Distilled.” I have also produced a video course on “Domain-Driven Design Distilled” and teach my IDDDWorkshop.com trainings globally. These are all ways to learn DDD from a self-taught approach and scaling up to live, intensive 3-day workshops. I think you should start by watching the “Domain-Driven Design Distilled” video training and include reading the “Domain-Driven Design Distilled” book. These are available online. “Implementing Domain-Driven Design” is a much larger book with lots of details, and can be used as an implementation reference or cookbook on projects. I also offer consulting services, even remotely, to help teams get jump started and to sustain DDD project such efforts.

Question #3 – What is your top DDD improvement recommendation for those who have been using DDD for a long time? What are they probably ignoring?

Mr Vernon – You must have conversations with domain experts. There is no substitute, because the conversations you have will result in the development of a Ubiquitous Language in a Bounded Context. This is the point of DDD, and yet not enough effort is made to accomplish building business and development relationships, or it is completely ignored. The DDD tactical patterns are not ideal unless using the strategic patterns, which begin with Bounded Context with a Ubiquitous Language. I have developed a Context Mapping Topography tool to help with this effort.

Question #4 – With the advent of Microservices, DDD is mentioned frequently as a useful reference about how to “split” a monolith. What are your top considerations for doing this?

Mr Vernon – DDD Bounded Contexts are a great first approach to architect and design Microservices. Many or even most developers are attracted to the “Micro” part of the name, attempting to give stringent rules to the “size” of a service. If you use DDD this concern relaxes because you are using the Ubiquitous Language to determine the size of the service, neither too big nor too small. After this, if you can prove a good reason to deploy parts of your Bounded Context in smaller units, that can be achieved without losing the goals of the Ubiquitous Language in context.

Question #5 – DDD is commonly associated with object-oriented programming. We know you have been advocating applying DDD while adopting the Actor Model and functional programming as well. Would you like to share your thoughts?

Mr Vernon – After seeing decades of inefficient use of modern hardware architectures that have immensely powerful computing facilities, many architects and developers have become aware of the need to change the way they view software implementation. This very much follows the Microservices architecture and how those play into Reactive. Functional programming is also growing in popularity. The Actor Model is not a new concept, and has been used in some of the most advanced, robust, even rock-solid, software solutions for decades.

Due to this, I have founded an open-source initiative to develop the actor-based reactive vlingo/PLATFORM. This is a substantial toolset that benefits both DDD and non-DDD Microservices projects. It supports Event-Driven, Message-Driven, Reactive, software development and is implemented for both the Java and .NET ecosystems. In early February 2020 we are preparing to release version 1.2.0 of the Java-based platform, and the .NET-based platform is nearing 1.0.0. We support Reactive DDD and Microservices using HTTP and messaging, and that use object and state storage, Event Sourcing, CQRS, and Process Managers (aka Sagas). We have a quick boot and plugin architecture. We also support Reactive Functional programming with the vlingo/PLATFORM.

Question #6 – What are your top bits of advice for developers in 2020?

Mr Vernon –  My current mantra is that all architects and developers must learn three things before they stand a chance at success:

1. Conway’s Law,
2. Conway’s Law,
3. Modularity.

The first two being the same is not a mistake. It emphasizes that when you think you have understood the effects of Conway’s Law on your software solutions, you need to learn even more and be even more aware. The need to be constantly aware of Conway’s Law cannot be overstated. It will determine the outcome of all solutions. The third thing is, learn to modularize your software. DDD can help a lot with all of this.