My approach had to show not just the “what,” but even more so the “how.”

JAXenter: The concept of domain-driven design was coined at the beginning of 2000. Eric Evans’ book “Domain-Driven Design: Tackling Complexity in the Heart of Software” was a landmark and is still widely received today. If you put yourself back a little into this early period: What problems did software development have before domain-driven design, which were then tackled by the DDD movement? What decisive difference did the DDD movement make to software development?

Truly, it’s no wonder that the industry produced so many failures and so many misguided “software developers.”

Vaughn Vernon: In my experience, software development had fallen into a downward spiral due to the introduction of what I considered very poor specification and design decisions introduced by industry leaders. To me, the J2EE (now JEE) specification was one of the single worst impacts on the Java ecosystem that had gained traction a few years prior. Literally the J2EE spec promoted the use of component types, such as EJB Entity Beans, that caused many failures. I am not certain that the specification team(s) understood what issues they would cause by their work. It could have been that their intentions were simply not properly communicated and backed by clear documentation and guiding patterns. It took years before accurate guidance was properly socialized.

This era was also taxing on the industry because the Dotcom boom was spreading quickly and not many startups and teams knew which technologies they should use. The Internet had become popular, and that’s what the boom was all about. The boom was happening among tool vendors as well, as they attempted to catch the industry’s financial upward trajectory. Under conditions such as those, the overwhelming number of signals driven by profit grabbing were very destabilizing. It became difficult to find exciting work unless your resume had the J2EE and EJB standout buzz. And yet, it was the broad (mis)use of J2EE and EJB that influenced so much failure.

SEE ALSO: Domain-Driven Design: Strategic Mapping with Wardley Maps

Next came the huge information pipe full of bad programming examples from sources that were mostly interested in the profit grab. So many new programmers entering the industry, and even experienced developers unfamiliar with the new technologies sought this guidance, which provided flawed software designs, from minute to the grand scopes.

Truly, it’s no wonder that the industry produced so many failures and so many misguided “software developers.”

JAXenter: How did you personally get in touch with DDD? What impulses / inspirations did the DDD movement give you during this time?

Vaughn Vernon: I had been using much of the things that were later named DDD. The teams I worked with sweated naming and developing fluent models. My exposure to domain models began in the 1980s when I began to learn both C++ and Smalltalk. I was already programming in C, and the idea of objects with C++ seemed very intriguing. However, when I dove into C++ there were problems, both with the dev tooling and environment as well as the language and how it was being used. I could talk for hours about this, but I will just say that I later learned how far from object-oriented C++ actually was. (I mean, when operator overloading and implicit casts became the favorite pastime of C++ developers, their resulting code was carefully obfuscated to consumers and later maintainers.

When I found out about Smalltalk and a curious little language named C-Talk and another named Objective-C, I began to understand objects. Smalltalk was such an incredibly productive development environment that I sometimes couldn’t believe how quickly I could get very complex problems solved.

There were some efforts to create C++ libraries that mimicked Smalltalk (the US National Institutes of Health developed one that provided Smalltalk-like collections), but there were always strange compromises.

So Smalltalk and the influence it had on my future use of C and C++ changed everything. And, Smalltalk was a natural expressive environment. Just about everything we did was effectively what today we would call “Internal DSLs.”

When I found out about Smalltalk and a curious little language named C-Talk and another named Objective-C, I began to understand objects.

Now, go back to the previous question/answer, and imagine my feelings. I love to develop software, and I love Smalltalk development even more, and then blend that with the mayhem happening all around me with J2EE and EJB and other incredibly weird technologies. I used to spend hours trying to explain to people why they didn’t want to use J2EE as its use was promoted (some parts such as EJB Session Beans made sense, as long as you were using TOPLink, and later Hibernate, behind them). I tried to explain MVC–no, real MVC–and how those concepts aligned with Web development, and it just didn’t get deep into peoples’ grey matter.

During this time, 15+ years after my initial use of C++ and Smalltalk, I learned about DDD. Someone mentioned Eric’s book as a source of helpful object-oriented patterns. I respected this veteran object practitioner’s opinion, so this book had to be good. That evening I drove to a tech bookstore that had “everything” (yes, those used to exist) and I bought Eric’s book. When I began reading, it immediately resonated with me. There were some things, of course, that seemed unclear, but lots of it was so encouraging. I finally found others with a similar background. And although I had never used the term “ubiquitous language,” it made sense because of my previous experience with developing business “languages” with small-ish teams composed of technical and non-technical members.

Ok, so there was this comforting affinity. Yet, Eric included some incredibly wise and fresh ideas that I had never heard of. These included the Bounded Context and Context Mapping. Much of the software I created tended to have boundaries with very focused models. That mostly happened as a result of what we were developing and the component-based technologies we used. It made sense to break different pieces of software apart, but it wasn’t because of the “business language” that we did so. Now this “different business drivers speak different languages within different boundaries” got the wheels turning faster in my head.

After gaining experience in the patterns of DDD, I spoke at meetups and local conferences about it. Yet, my talks didn’t have big audiences. Rather, the talks about database technologies had big audiences. With my sincere efforts to help, I could not understand how something so right could be ignored, or worse, rejected, by most developers. In essence I had become even more sure of my experiences with design because of my newfound sounding board, but the attitude of the developers around me didn’t change. I could point at this brilliant blue book, but I wasn’t making enough of an impact on my own aspirations.

JAXenter: With your book “Implementing Domain-Driven Design” you made an important contribution to the adoption of DDD. What was your approach, your motivation for the book? What ideas did you want to add, elaborate, specify?

Vaughn Vernon: In case my story isn’t making a clear point, I will be explicit. Nothing is easy in the software industry other than failure.

Nothing is easy in the software industry other than failure.

Since I wanted to do what I was convinced about, I had a lot of work to do. I can’t use DDD unless others use DDD, which means I had to convince others to use DDD. Since learning to develop software some 36 years ago, hard work has never frightened me or made me overly exhausted as a result. Software development is creative. Creating is rewarding. Creating releases some kind of chemicals in my brain that deliver incredibly positive intellectual and emotional satisfaction. It’s not hard for me to do it. It’s hard for me not to do it. I hope others reach that sensation as often as I do.

My approach had to show not just the “what,” but even more so the “how.” Eric’s book left those who were determined to read it with a very strong impression that DDD is fantastic. Still, they would also wonder, “how can I put this kind of fantastic into practice in my world?” My explanations had to be much more code prolific and use examples that software developers would readily understand.

I also noticed that there had been efforts made to explain DDD using C# and the .NET Framework, but there was little to nothing about using DDD with Java. Since Java was the language that I mostly used on projects, this seemed to me a shame. Also since J2EE was to my mind such a disaster to all but a limited set of diehards, I would have to show DDD on top of the Spring Framework. In my estimation, Spring had already all but eliminated J2EE as a viable specification. Thus, it only made sense to put DDD and Spring in front of others because Java developers were most likely already using Spring. Even so, I purposely didn’t overwhelm my readers with Spring. I showed enough to prove that DDD could be hosted by contemporary, popular frameworks.

I had watched enough of Eric’s conference presentations to know that he wished he had placed the strategic patterns in the front of his book rather than the back. Although I agree, I have a theory on why it’s best that he didn’t do that. Since software developers are more attracted to technology, and the tactical patterns are closer to technology, Eric’s “mistake” in placing the tactical patterns up front was actually the reason for peoples’ attraction to DDD. I may be wrong, but I know that developers tend to resonate with the tactical patterns but struggle with the strategic patterns. If they had encountered the strategy first, they may have quit reading.

With this developer bias in mind I decided that I would paint a word picture around teams using the DDD tactical patterns while ignoring the strategic, and how that got them into a lot of trouble. Following the teams reaching dead ends, I would show how they found and learned about the reverse gear, turned the vehicle around, and then headed in the right direction. That is, they discovered the back of Eric’s book, put the strategic patterns in first priority, and they did so to their ultimate benefit.

JAXenter: The basic principles of DDD are known to many by now. But putting them into practice is anything but trivial. Do you have a tip for the readers here? How can you start with DDD in a project?

Vaughn Vernon: I have realized that most software developers and teams are missing some very essential knowledge that they need to acquire before they even start to think about putting DDD to use. I like to say that teams need to learn three critical things first.

1. Conway’s Law
2. Conway’s Law
3. Modularization

No, it’s not a mistake that 1 and 2 are both Conway’s Law. This emphasizes that teams don’t generally understand that the structure of their organization, and how that influences communication, will determine the result of the software they deliver. If your teams don’t talk, you will have a lot of conflicting and confusing meanings among the components across a given software system. If your teams are structured against your software goals, your goals will not be fully met. Expect that your software will amplify your team’s ability to communicate clearly and deeply.

Software development is creative. Creating is rewarding.

After you’ve understood this, you can then comprehend how your team’s communication should influence the modularization of your software components. But you have to be aware of this as a goal. When you find that the subject of your communication changes contexts, it’s a great indication that you must separate the conversations into explicit models using modules. When the separate explicit models, each in different modules, collaborate or integrate, try to make the exchanges between the modules loosely connected.

These “three” critical things are the foundations of DDD. I have just introduced the concept of a Ubiquitous Language that is the result of team communication. I have introduced the concept of the Bounded Context that is the modularization around the specific kinds of conversations. And I have introduced Context Mapping between the modularized models that must collaborate and integrate.

Now determine which Context Mapping patterns should be used between the module-based Bounded Contexts, and which tactical patterns should be used inside each module-based Bounded Context.

This won’t be easy, but you can be determined to keep it simple. Don’t place the network between your modules too early, or at all. The modules can be hosted in a single (J)VM for quite a while, at a minimum. This will take distributed computing out of the equation early on. Distributed computing introduces all kinds of unnecessary complexity. Early on, understanding the business drivers and rendering these into software models matter most.

JAXenter: If we look at today’s discussions about software architecture, DDD is still very relevant. In the context of the microservices debate we might even experience something like a revival of DDD principles. What do you think about microservices? Are microservices the very essence of what DDD is all about?

My advice, as partially stated above, is to first modularize inside a single (J)VM.

Vaughn Vernon: My advice, as partially stated above, is to first modularize inside a single (J)VM. Create the exact same kinds of Context Mapping connections between the modules, but without the network. Then determine whether there are significant team and technical drivers to break the modules into separate (J)VMs and on separate compute nodes. These might include:

1. A different rate of change between modules that causes CI/CD friction.
2. Due to the demands of communication and goals, should a single team be divided into two or more teams?
3. Does a single module or a smaller part of a single module require a greater scale than other modules?
4. Does a single module or a smaller part of a single module require higher throughput or other performance requirements than other modules?

If so, you have a reason to take one or more of the modules out of the single (J)VM deployment. For example, say that the modular monolith that you’ve created has five major modules. If you can justify breaking all five of these into separate (J)VMs and deployment units, you will have five Microservices that align one-to-one with Bounded Contexts. Since Bounded Contexts tend to be relatively small due to the focus of a given Ubiquitous Language, a Bounded Context as a Microservice is a good first goal. If some of the drivers, such as 3 and 4 above, require further decomposition, understand that such drivers are not a business linguistic drivers, but technical drivers. The Bounded Contexts don’t change even though the deployment units do.

JAXenter: Which aspect of DDD is most neglected in practice today?

Vaughn Vernon: Conversations between developers and business stakeholders. DDD refers to the business stakeholders, who have significant understanding of the system’s goals, as domain experts. I find that this failure to communicate happens for a few reasons.

1. Identifying who is actually an expert is difficult. Note in this case that some domains are so new and novel that there may not be any true experts. The business experts must be built on the fly through the investment of communicative innovation.
2. Business experts exist but refuse to engage or find it difficult to spend the necessary time. In this case, find a way to accelerate what you need to accomplish with their involvement. Also, don’t spend any of this time trying to correct them on technology or anything at all. Just use what they have to give.
3. This may surprise many, but my observation is that often times it’s actually the architects and developers who don’t want to communicate with business experts, or even other developers. This is generally an introvert’s preference or technical prejudice against business people, or just emotional intelligence that’s equal to the task of speaking kindly and productively with other people.

As I said previously, if you aren’t very conscious about the effects of Conway’s Law on your projects, you will pay with inferior results.

JAXenter: You’re currently working extensively on Reactive Programming. What is the relationship between Reactive and DDD? Is there a closer connection?

Vaughn Vernon: Yes, I think so. For me personally, I find that the use of the Actor Model is a great way to think about solving business problems. Each actor, which is basically an object, has a communication protocol that aligns very closely with a portion of a team’s Ubiquitous Language in a Bounded Context. Again, the language is developed using explicit communication, and you design the actor objects to communicate using that same language.

For me personally, I find that the use of the Actor Model is a great way to think about solving business problems.

The Actor Model also provides some very beneficial technical features that address modern hardware architectures and cloud infrastructures. Actors communicate asynchronously with one another by sending messages. This is different from typical objects that use direct method invocations that block the caller. When using our vlingo/PLATFORM, the technical communication style feels like a common method invocation, but under the covers it operates as asynchronous message sending.

The asynchronous message sending is extremely important for today’s hardware architectures because it enables the use of all cores and hyperthreads in a non-blocking manner. Overall, the throughput of the entire solution is more efficient than when using blocking direct method invocations. Overall this also enables greater scalability in a given (J)VM, across a cluster, and throughout a system.

The way that messages are delivered to actors, that is one at a time in sequence, makes for perfect transactional boundaries that may never experience database races that cause data conflicts and transactional failures.

SEE ALSO: Testing Java microservices applications

Potentially these actor-based objects can be cached in memory for a long time as long as they remain “hot”; that is, frequently used. If an infrequently used actor is evicted from memory, its state is safely persisted so it can be quickly reconstituted as its next message arrives.

You must understand that such capabilities are not afforded the older, legacy container-based frameworks that most developers have used for years. Legacy frameworks suffer from the innovator’s dilemma and will never be able to fully transform into what is needed for the future of software development.

Our vlingo/PLATFORM has recently reached the outstanding 1.0.0 GA milestone. It is fully reactive through-and-through. It is simple to learn and adopt. I am sharing more about this in a related article that I have written for your publication.

JAXenter: Which aspect of the current discussion about DDD and software architecture in general do you find particularly exciting at the moment?

Humans communicate using messaging, and imitating human communication by means of actor-based objects is a great way to use DDD effectively.

Vaughn Vernon: My preferences are around messaging from the very small scale to the very large scale. Alan Kay, the creator of the term “Object-Oriented” and the Smalltalk language said that the interesting things about objects are the messages between them. Alan Kay always considered objects to be message processors, and that’s just how Smalltalk was designed. Every Smalltalk object alive in the (S)JM is a message processor.

I am involved in two companies that are under the same ownership. One is Kalele and the other is VLINGO. The name Kalele is the Hawaiian word for messaging. The name VLINGO is about communicating a Ubiquitous Language–the lingo–between actor-based objects.

Messaging is such a classy way to decouple software components, where the protocol defines the messages that can be sent and received, and that align with the language spoken by a DDD team. Humans communicate using messaging, and imitating human communication by means of actor-based objects is a great way to use DDD effectively.

The post My approach had to show not just the “what,” but even more so the “how.” appeared first on JAXenter.