00:00:23.910
Thank you very much. Let's see if we can get a picture here—it would be amazing. Oh, yeah! The picture worked; wonderful!
00:00:30.060
Good evening, world. Slav! This is my very first Ruby conference, and it's amazing to see so many Ruby developers who actually practice Ruby. I didn't know that.
00:00:41.940
Since this is not the official keynote but the first talk of the conference, I consider myself now a Ruby developer conference keynote speaker. Cool!
00:00:52.500
So, I'm not talking about Ruby tonight. I'm discussing something that is programming language agnostic—domain-driven design.
00:01:05.070
To get a picture of the room, who here has heard of domain-driven design before this talk? Almost everybody? Great!
00:01:10.290
Cool! I'm glad to see that.
00:01:15.600
So, I personally hate presentations that just show you what you've done in your career, as nobody really cares. I love domain-driven design to a very unhealthy degree. Today, I woke up at 4 o'clock, took a train, missed my flight, took the next plane, and arrived here just 30 minutes before this talk starts.
00:01:38.880
And I will leave tomorrow morning at 5, but I will have a party with all of you guys afterward and talk about domain-driven design for the rest of the night.
00:01:50.670
Please applaud me after the beer! By the way, I also started the German domain-driven design community and founded a small conference that takes place annually in Berlin in October. So, if any of you wants to go to Berlin and talk about DDD, learn a lot, and take part in hands-on workshops, fliers are available here at the entrance. Please join us in October.
00:02:02.909
Now, let's talk about domain-driven design. I want to give you a small overview of what domain-driven design is, and especially what it's not, because there seems to be some confusion in the industry.
00:02:07.950
I want to discuss when to use domain-driven design in your projects and who should learn about it. We will go through an example of how to do DDD together; we will actually work together to build a small domain and a domain model that we can implement.
00:02:27.750
Later, depending on the good weather outside, we will discuss why we do domain-driven design and what the risks and side effects are if you do it, because nothing in this world is free; everything is a trade-off, including DDD. Even though I love it, there are certain cases where it can be risky or where you might not want to use it.
00:02:40.200
So, what is domain-driven design? Domain-driven design was a book by Eric Evans, published in 2004, with the subtitle "Tackling Complexity in the Heart of Software." This isn't about the complexity of technical frameworks; instead, it's about the complexity of the business that you are trying to implement in working software.
00:02:58.140
He wrote this at a time when most developers were Java developers working on business software, dealing with third normal form databases and object-oriented programming—the state of the art in 2003. The common interest then was the next framework or ORM, not really about the business.
00:03:19.920
What Eric tried to solve in his book was how to bridge the gap between business people and programmers. The idea is to have a slim mapping where business people talk to programmers, who look into code and translate back what the code does to the business people. We want to make this mapping as lean as possible.
00:03:45.870
Now, the ideal situation is having a ubiquitous language—a term that is quite hard to pronounce but is significant in DDD. Ubiquitous language refers to the language used consistently in all facets of the business problem. It's both spoken and written, appearing in the code, in the minds of the users, and in the documentation.
00:04:22.110
However, it doesn't come naturally; ubiquitous language is something you design and develop. You start with your natural language—be it Polish, German, English, or whatever the users speak—and advance to a business language that has specific terms relevant to your industry.
00:04:41.910
There are often potential ambiguities in language. For example, in a business context, terms like 'employee' or 'colleague' may essentially refer to the same thing but can lead to confusion in code. We aim to create a shared vocabulary or a single term that everyone agrees upon and understands in the context of your domain.
00:05:11.550
Let's define a ubiquitous language based on a common understanding. For instance, consider our living room: tonight, I am going to sit on my multi-seat sofa—maybe alone, maybe with friends—and we will watch movies on an entertainment provider system.
00:05:36.030
While it seems like good code—something we've all likely written—the problem is the abundance of weasel words. These are prefixes and suffixes that clutter class names and methods and provide no additional meaning in terms of domain understanding.
00:05:59.250
When we write or read domain code, we primarily want to focus on business cases and behaviors. So, let’s delve deeper into why we get caught up with these weasel words and how they infiltrate our source code, affecting our domain-driven design negatively.
00:06:19.920
For example, using terms like 'my customer' or relying on Hungarian notation, like prefixing with 'B' for boolean types, doesn’t add value. Once we understand the business case, the details can often be irrelevant. If I say, 'I pay you your salary,' you shouldn’t care if ‘salary’ is represented as an integer or a decimal in the code.
00:07:15.600
We often fill our code with terms that don’t add meaning. Class names like 'CustomerRepository' can confuse people who aren't privy to the terminology and architecture you've implemented. This can cloud understanding and ultimately lead to poorer collaboration and outcomes, compromising the quality of communication around domain rules.
00:08:13.020
Instead, we want to focus on the actual business objects and behaviors, showcasing them as they are in human conversations. Therefore, our goal should be refining what we present in our messaging between our domain behavior and application logic.
00:08:59.550
Though we may struggle against the norms, we should emphasize that a good naming convention enhances clarity and readability. Avoiding clutter created by unnecessary prefixes and suffixes allows our code to be more accessible and allows others who join the codebase later on to understand the purpose and functionality at a glance.
00:09:53.860
When conferring with business experts, it’s crucial to remain alert and adaptive. Our aim is to collaboratively shape a language or vocabulary that resonates with everyone involved in the process—be it in meetings, development, or documentation. Aligning the code language with colloquial business language will then ease communication barriers in future discussions concerning functionality.
00:10:46.740
By recognizing individual perspectives, we can hone our design practices to reflect greater articulation and understanding in our business motivations. Thus, through conscious effort in developing a ubiquitous language, we can bridge gaps that once hindered collaboration.
00:11:04.210
In closing, an effective domain-driven design that embraces a ubiquitous language allows teams to foster healthy dialogue and yielding feedback that guide improvement in products and processes together.
00:11:24.410
Thank you very much, and I'll now open the floor for questions.
