Alberto Brandolini - Domain-Driven Design in Productland

[00:00:04] Hello, hello, welcome back. We are um starting again, uh two more conferences before the end of the first day.
[00:00:20] And now we are receiving, we are hosting uh Alberto Brandolini. Maybe you already know him. We are very delighted to have him again at the flow conference. I think last time uh Alberto didn't make it. So, quite happy he's here with us today and we are going to hear some stories about DDD in product land.
[00:00:48] Thank you.
[00:00:55] Uh, well, thank you for being here. This is uh uh complicated experience for me. The the story, well, about me, well, you probably know something a little bit about even storming and and the thing, a lot about domain-driven design. But that's not the most important thing, the most important reason for being here. So, the the reason, now I have not to walk. Uh, the reason uh behind this this talk is uh, well, a lot of people are trying to apply domain-driven design ideas in a in a different scenario like uh the product space. And I wanted to explore it. And uh, and it turned out it was a absolutely massive rabbit hole. So, the first time I submitted this talk, the the scope was very, very generic and I ended up having something like uh four times the material needed to deliver a talk. And that was, yeah, one year ago, more or less.
[00:01:54] And they liked the title here. So, I tried again and then I submitted again, I rewrote the entire talk and I ended up with a lot more material. So, this is my trouble and this is the thing that I will try to handle, manage for the entire for the entire talk. So, talking about the starting point, we're talking about product development and we are talking about domain-driven design. And it's just like mixing apples and oranges, uh, and I need to clarify a little. Just a, a lot of people are trying to do domain-driven design, unfortunately. I'm a little bit of analist. Domain-driven design is probably getting mainstream, but there's something that we need to fix. Um, a couple of thinking tools about notation, I will try to apply a few principles. Uh, one is making the implicit explicit. In some places like the surface discussion is just like not good enough. The other thing that happens many times is, oh, well, it's not exactly my context, it depends. I try to make the end depend, it depends thing visible with this uh arrow plus, yeah, some practical ideas where where I can. Now, how many of you are familiar with domain-driven design already?
[00:03:08] Okay, half of the audience. Very, very quick recap from different perspectives. Um, Domain-driven design in terms of philosophy, it's is really based on continuous learning, try to understand the deeper complexity of a domain and try to do this in a collaborative way. Well, so sounds really cool. There's something really specific about the language awareness, like uh we don't trust the language, we use it as a tool, but we know we need something more sophisticated. And the original ideas are ubiquitous language and bounded context. In terms of strategy, there's the idea of focusing where it really matters because doing great stuff where it doesn't matter, well, it's a waste of our time and also uh stakeholder's money. Uh, in terms of architecture, for many years, the original books, they felt like domain-driven design was an architectural approach. also kind of prescriptive like if you remember all the discussion about entities, value objects, aggregates, services and doing object-oriented very clean. That's not the whole story right now. The whole story behind it was uh we needed an architecture for continuous rewriting and that was the only one available in 2004. Now we have a little bit more options. In terms of design, one of the key principle is
[00:04:28] not having only one model, having more models specialized for different purposes. And this fits very well the notion of working with inside a large organization, uh that has many purposes, like billing is different from managing shipping and uh and uh sales and and also maybe something for other departments. Different purposes, different needs, independent models. And in terms of implementation, there's a strong focus about building robust building blocks. Okay, good stuff.
[00:04:58] Let's see how it does fit. Uh, from the from the product side, this is this is where I'm a little bit of a newbie. I mean, I'm not exactly the the last one joining the discussion, but at the same time, this is not where I'm coming from, I come from software development. And so there might be some over simplification about what is a product perspective. For me, it used to be the other side. And um, I couldn't make it fit in inside the categories. But there's a lot of discussion about having a core strategy, going into experiments, focusing on value and also different interpretation of the term design. Not so much about language, architecture or implementation. Okay. So far, so good. So, the first thing I would like to look at is is the mindset.
[00:05:49] Both sides now seems to be driven by curiosity and and the common approach seems to be continuous learning. We want to learn about the domain, we want to learn about our customer goods, we want to grow together, being better by continuous learning. Seems like easy.
[00:06:09] Except, first problem we encountered in this space was, who is doing the learning? When I mean who is doing the learning, it's the first conflict when we try to apply domain-driven design in in a product organization. Or when a product mindset try to approach a DDD team is uh
[00:06:31] we are trying to learn together, we have different workshops with different techniques, scheduled at different times and sometimes the stakeholder cannot be available for both workshops and feels like redundant. Are we doing even if DDD proposed ideas like the modeling where for and uh collaborative modeling uh tools like uh, well, event storming domain storytelling and so on, well, we already did the workshop sometimes. Also at many times is driven by who has the biggest uh budget before starting. And uh and so the the feeling is uh in many product companies, oh, we're already done the learning. And this is a design blueprint. This is what we get and uh and even if the mindset is the same, there's some other blockers in the way. Um, also, not not to mention the problem coming from above somehow. Like uh the cultures behind the people were different. And in uh in many universities, the lessons that were taught, especially to the younger designers or developers, were something like you're doing a good job, you will have to tell other people what to do. And this is happening on both tribes, not exactly the best place for starting a collaboration. Um, so the thing that we discovered, especially in in places where people were coming from different backgrounds, but also sometimes different suppliers or all of these segregated learning. I'm doing this user research and I'm just sharing the summary, just slowing everything down. We were trying to learn something with the domain experts, other people were trying to learn something really similar but not exactly the same thing with the expert and this was creating a slow motion on the expert availability.
[00:08:22] Not to mention that the idea of expert, if you are in product land, might be slightly different.
[00:08:29] And it's way more interesting, if you can play experimenting in this place, uh, to, um, yeah, go across discipline learning. And I mentioned even storming because that's my baby, but it's not the only thing. I would say the space for cross-discipline learning is pretty wide and maybe tools like Miro are way more interesting in terms of we could have many, many different views in the same place than a single discipline. The thing I like about about even storming, it just it can help having different perspectives on the same on the same workshop.
[00:09:07] But the thing here is it requires, part of the mindset, to drop some of your uh specialized tools and to get in a land where even the notation might be part of a negotiation.
[00:09:21] So, in general, the the thing that worked was somehow resonated with the uh this morning keynote from from Sander. Like uh we tried to create an environment when conversation between different disciplines were were happening. Well, interesting, in in in one scenario, one of the most effective tool for creating this cross-discipline collaboration collaboration was having a Slack channel. without anybody from the customer side, that was not exactly a product environment. But that was one thing creating the safety for for a good collaboration between between experts. But in general, we started dropping the exclusivity of access to many, many tools. Everybody could have less barriers to talk with people from different areas and also to access tools uh uh on that were using in the exploration.
[00:10:20] One of the first uh casualties of this approach is just uh, well, forget optimization. I mean, it's not even optimization, it's usually local optimization. If you are the design team, you try to optimize for the workload of the design team. If you are the development team, you try to optimize for your own workload. It's suboptimal in the whole. It just it totally requires seeing things from from a larger perspective. So, yeah, just drop it, part of the game. Um, another tool that was that is part of my favorite background, but it it it also comes from from different sources is you need something to make
[00:11:04] a grounded collaboration about complex stuff possible. And large visualization tools uh are really good good tool about it. There's something really interesting about the idea of Obea in the book, the collaboration equation, uh but this is an example of something that we've done in in in one scenario. Uh we still used uh Miro here, we hybrid the notation. So, there's something which is um screenshot taken from from a website, uh other areas exploring uh even storming process modeling notation. Plus a lot of commit, plus a lot of disclaimers like this is our current understanding of the behavior of this department.
[00:11:51] Please help us.
[00:11:54] Um, really, really weaky attitude, but we try to put a place where everything is visible, especially the connection between different areas.
[00:12:04] And but there's another thing that was uh that was uh interesting. Like uh everybody was driven by curiosity. It doesn't mean we share the same mindset. So, the actual answer to this question is, no. We are curious, but our curiosity is different. So, we are we're not getting exactly in the same place, but the conversation is important. What do I mean with this? I mean, as a technical people, and everybody in in our team from the technical side was really, really biased into trying to find the perfect solution to the problem. hoping that the solution would be a piece of software. And that's something that is very hard to remove from the developer's brain, like this is how we solve the problem, writing more stuff. We need somebody else in the team. So, just don't do it alone, don't assume that you can do it, we still need all the different perspectives.
[00:13:00] Let's look still part of the learning path, let's talk a little bit about strategy. Because one of the thing that was a bigger change from the DDD perspective to uh the product mindset is is the fact that if we are reading a business end to end. This is what we do in usually big picture uh uh even storming, we try to assess what what everything that happens inside a business line. touching all the different departments. And uh and this will allow us to discover what might be the current biggest bottleneck for the organization. This is what we do when developing software solution for an organization. So, not a product custom software. What is the advantage for DDD people? The advantage is the most important problem to solve is very likely to be deterministic. We we have clear indicator of the most important thing to do right here, right now, is solving that problem. People are voting, people are talking about everything and selecting something. I have, let's say, an extreme confidence, maybe not on the solution, but on the fact that if I solve this, everybody's going to be happy. Well, that is, that is good.
[00:14:20] We have the privilege of chasing only one target. Okay, this goes away when you work with the product. It's just like you cannot select your target in a form of bird, I'm going to catch that bird. You can't. You you it the more potential customers you have, all you care about is customers, money, subscription, not exactly that one. And this, this is a big shift in the mindset also for the for the development team. So, product development is not deterministic, not as much as we wanted, at least. And one of the possible outcomes is, oh, okay, no problem. Just tell me what you do, you choose the hypothesis, you do your bets and uh and I will implement what is what is important. You take all the risk. And uh, maybe that's not the best attitude.
[00:15:15] The other thing is, we would like to be in a place where we do continuous experiments. And this is not exactly how a traditional software development backlog looks like. And this creates quite a few tensions here. One tension is we want to run the experiments and we want to learn. That was an interesting and disappointing, disappointing surprise depending on the perspective. So, of course, you cannot learn without data. You need result from the experiments and you want them to be measurable. And the problem is, where is your data coming from?
[00:15:54] And this is where a different architecture could make a lot of difference. So, this is uh a cleaned up story from a real scenario, uh, we we we needed to detect a situation where we had booking transfers. And we had to work integrating with a very old database-centric legacy architecture. And uh, well, the the answer was that. We don't have transfers, like transfer is not a key information in our domain, it's not a concept in our domain, we have it in the real world but not on the database. Okay, great idea, we can run a query that detects if they have been cancellation followed by a new booking by the same customer and managed by the same salesperson. And uh, and everybody said, yeah, yeah, great idea. Great, let's put it as part of the daily scripts running at the end of the day, playing with data and making it readable if we need to detect cancellation. And that was the conversation we had. And this is a snapshot of me while looking at listening to this conversation. I was completely freaking out.
[00:17:11] Like uh you're missing a key concept and you're creating accidental complexity to handle this information downstream. Now, that's that's totally insane.
[00:17:24] So, one of the places where actually DDD can make a difference in the product space. If you need to learn, the more you can capture deterministically about the behavior of your user, the clearer and cleaner and faster are going to be your discussion. So, if you have an anemic monolith, if you everything is a crud or playing with data behind the scenes. Sorry. Uh, then what what you have to do in order to understand what is happening, you add a layer of interpretation usually in BI. And this leads to questionable data. And this questionable leads to trouble. If you have a richer event-driven models,
[00:18:05] well, what you get is something a little bit more sophisticated. Less prone to interpretation. And also, you don't have to recreate the logic, you have it as a first-class citizen. And this leads in a cheaper way into unquestionable data. Little alert here, if you already have specialist in in a given position and payroll, there might be inertia at the organizational level. Oh, this is what I do, this is what you paid me, so we'll keep doing this.
[00:18:38] Uh, but uh, yes, when I realized this, I was, oh, completely freaking out.
[00:18:45] Every implementation could be good for your product. Hmm, some implementations are better. Maybe not in the way the product behaves, but uh, well, also there, I would say as a personal taste, but the advantages might be in places outside the actual uh software product but in the observability of the product itself.
[00:19:09] Uh,
[00:19:12] the other thing that was really annoying was uh if you get into questionable data, then all of your cycle of discussion becomes toxic. So, the moment we couldn't trust the data because uh how what is the percentage of
[00:19:29] potential mistakes in our interpretation of the downstream behavior. It was really, really so ambiguous that the discussion stopped being on data and started being on who's in charge. I've been doing this work for 10 years, you're the only one raising this problem and uh, not exactly the nicest discussion I wanted to be in.
[00:19:54] So, there's there's another kind of war that might need to be open. That has to do with interpreting the data. And uh, and the more discussion we had in this place, the more we realized that uh biases and logical fallacies were actually problem number one. We wanted to have a critical discussion about about data and behavior we were detecting, and that was not exactly easy.
[00:20:22] And um, because yeah, pressure, because power and so on. So, if there is one more reason to go uh with the so-called product triad, so having uh business, engineering and design on the uh on the same discussion, this is one. Like uh it helps reducing the impact of biases on strategic choices, it helps seeing things from different perspective. But more realistically, it increases the probability of having at least one critical thinker in the room. In in the worst cases, you have three people. Not a critical thinker. Hmm, that might not be the best place to be.
[00:20:20] And because yeah, pressure, because power and so on. So if there is one more reason to go uh with the so-called product triad, so having uh business, engineering and design on the uh on the same discussion, this is one, like uh, it helps reducing the impact of biases on strategic choices, it helps seeing things from different perspective, but more realistically, it increases the probability of having at least one critical thinker in the room. In in the worst cases, you have three people, not a critical thinker. That might not be the best place to be.
[00:21:05] Switching perspective, again. So the moment you collaborate, the moment you collaborate with uh experiment with a larger team, then flow starts becoming a problem. It's not strictly a DDD problem, but you have flow flow in the name of your conference. So a little bit of of context here.
[00:21:31] There are plenty of discussion and I took this uh this uh blog post from uh Pavel Samsonov here as a as a representative because it's deep, it's uh it it was also painful for me to read, uh but uh it hits a nerve. So from the point of view of design and product experimentation, Agile seems to be a cage. And I've been been to Agile from, yeah, a long time and no, no, no, we were supposed to be the fast ones. And uh so what what's going on in here? Uh a lot of discussion about this. The article is very, very interesting, even if I I don't agree with everything, but I think the pain is really real. And this is one of the perception that is uh that is behind the scene. The thing is, this is reinforcing a problem behind the scene, which is kind of uh tribal culture on on different sides. And it's on the software development side or on the DDD side and also on the design side, not to mention other uh possible uh professions joining the uh the discussion. Every side has a preferred way of doing things and they might be exposed to a not exactly the best interpretation of the dogmas of of the other side. So, well, what we wanted to uh analyze, just let's look where are we right now, because the the dogmas were not were not exactly right. So one of the parameters was how responsive is your that team is uh um, in some teams, well, we have this idea with the experiment, okay, well, we can run the experiment by the end of July, not exactly the best place to be, but there's probably a lot of tech debt behind the scenes. The the intermediate that might be annoying, like we can go live in the next print, but you still have to wait 15 days or two weeks to get to get something. And that's not what you want for a for a little experiment to challenge some assumption. So that might be the classical scrum cage uh in in in action. Uh, we've been in a place where we had a very smart team that could go live with an experiment within a day provided the people were not overloaded with extra stuff, so but technically it was feasible and the design was robust. But this requires good practices and integrity and maybe it's not the most frequent thing to find. There are realities, but maybe these are not the realities behind it and this might be fueling this tribalism that I was mentioning. The thing that was relevant for me is if your design is robust, having options for experiments becomes easier. The thing that we were really proud of was, okay, we built an infrastructure this way and we have this idea for an experiment, okay, easy. We have this idea, okay, easy. Well, this requires a little bit more work on the UI. We have this idea of this experiment, okay, we can do this. So the options were in place, the flexibility was in place. Every time we had a little negotiation about doing this in a way that was safe for the business, for the software and for the people involved, but it was always uh always doable. Except most of the discussion, if you drill down, they are referring to teams that are not exactly in this position. So, let's say, don't trust the internet, it might be the summary of the discussion here. But the most interesting part here is, try to find a way to break barriers. This will provide options for better collaboration between different parties involved. Let's have a look at what happened on the on the our uh board. Um and the problem that we are facing and I guess many of you are facing if you are in this space, is just there are so many different concern inside the actually limited physical space or logical space if you're going live. I'm still a fan of the physical boards and maybe that's going to be clearer. So from left to right, we have something which are just unstructured insights, little ideas, like uh, I think maybe we could do something better on the subscription page. Or the wording is not clear and blah, blah, blah, not something which is sophisticated. Or maybe something unstructured coming from the customer feedback. Just there's there's
[00:26:08] unstructured sources of information, there's chaos pushing information inside our backlog. We need a way to structure and work on this and there are many uh many ideas. The one I like most is the uh opportunity solution trees that that's how more or less how I try to visualize the structure insights, like uh there's many ideas, we still need a group of people reasoning about it. From now on, it becomes a little bit more predictable flow. Even even though that traditionally, uh we would have a design team working on on features and then providing blueprints to the uh implementation team, to the development team putting them in production. There's a lot of space, not to mention while a final review and uh after the the the stuff is developed. There's different items like uh refactoring is not a concern for the design teams many times, even if it's possible, not part of the experiment, but uh features and experiment might live in the in the same place. This is the problem or one of the problems. If you go digital, you will never see this. All the information that are part of the Kanban culture, big visible models understanding the constraint, we don't see them online. And uh because because you can only see a given set of uh columns in the screen, okay, you can move the screen, you can scroll left to right, but then you miss the impact. And uh and that's one of the casualties of working remotely, I would say. And uh and the other thing that we lost is, okay, one out of the flow is big and there's a lot of people involved like, but if we have a bottleneck of one person, it's almost invisible on a digital board. You need the person to be able to say like, look, too much stuff involves me, looks like everything is on me and doesn't really work. And uh yeah, that's a little little question for for everybody. How much are your digital tools hiding?
[00:28:15] Um, we worked on this a little, we tried to shrink, we realized that having a cascading setup, uh design and then uh, um implementation was not a good idea, and so we shrank the flow a little. We still keep the separation of the unstructured items, the the conceptualization area is part of the flow. Uh, what I wanted to show was uh basically in in our setting, the development team was involved almost in everything, the design team was involved almost in everything except the development of of the actual uh software. And the business team was part of the original design and then part of the reviews review stuff. So not bad, even if there was some uh some tension. The thing that was really interesting was by shortening the flow, we also changed the notion like design should always happen before software development. It's still the mainstream idea, but not the only way and before it could be different. The other thing that was clear was explicit handoff were wasteful. Especially when the artifact were too detailed, we didn't need them. And uh and also reinforce the possibility of, oh, you didn't understand my blueprint or or anything. So, in in practice, a thing that we uh we we've done and was working very well was uh reducing frictions by pairing and having a lot of collaboration at the instead of the the handoffs. pairing uh across disciplines so that, okay, I only need this, I don't need the whole stuff. That was working very well. It was it looked really good, except when we hit situation where technical debt was overloading the technical team, the technical team didn't have the time to participate in some of the activities. So they ended up being downstream again in that situation. It was nice to be part of this discussion, but not overloaded with the old stuff. Okay. So, ideas, uh build tools for cooperation. Make it possible, remove the impediments. It's a lot harder if you do it remotely, but we can have tools for remote cooperation. You can do great stuff with Figma, you can do great stuff with Miro, um, Slack and and creating places for spontaneous random conversation, uh just do them, make make it easy to get in touch with the other people. And one of the good thing about product environment, it usually you don't have so many external suppliers, so this reduces some of of the barriers already. And uh little note, technical depth is distracting the engineering team, be serious about it. That's would not be the only place where I mentioned this problem.
[00:31:14] Now, this is probably the toughest part, meaning that domain driven design is very, very specific and peculiar about the language, while uh well, product management doesn't really care or maybe there's something about the language. So I need to and I also need to realize that some of the dogmas of domain driven design don't really work here. So, one of the key ideas of domain driven design was ubiquitous language. You can't say you're doing DDD without mentioning it. What is ubiquitous language? Ubiquitous language it comes from the idea, for the realization that in order to understand the domain complexity, we talk with people.
[00:31:59] Doesn't take a genius to understand this. The thing is, when we talk with people, we use a language and we trust the language thinking it can convey clear and unambiguous information from your brain to mine and vice versa. Well, it doesn't work like that.
[00:32:19] Language is a trustworthy bastard, I would say. It doesn't give you the precision we need in order to develop software. Uh, conversationally wise, we can do jokes and and talk about stuff and then accommodate the ambiguity. Implementation wise, we need binary precision. Conversational languages don't have this binary precision. Okay, now let's build one. So the whole idea of ubiquitous languages, we need a language that could still be used in conversation, that has the same precision of an implementation language, of a of a programming language. It's not something that happens spontaneously, it's something that we craft and hammer and sharpen every single conversation. We try with different uh terms, we pick the one that works better, provides better insight, and we improve our language. And when I say our language, I mean in the first phases, the development team it's tries to capture as much as possible of the language from the domain expert. In the second phase, development team and uh domain expert are refining the language, injecting the precision that might have not been in the original language. It's a continuous work. The result is a dedicated single purpose language with every term has only one meaning and one limitation, this only happens inside a specific bubble called a bounded context.
[00:33:58] Okay, that's that is the theory and uh it works, it's it's one of the best ideas of domain driven design, except we might not realize what is the foundation behind it.
[00:34:14] So the other the competing paradigm is what is called canonical language. And that was also how the the ubiquitous language has a language has been interpreted for a long time. So a single language shared by everybody. It's uh it's a nice idea, uh sounds like uh like great, like everybody should speak the same language, except in the DDD community, we know it very well. We have a problem, this is my nightmare when I travel, and it also shows that the human race completely failed on a very simple problem, like how to find the common standard for two, three holes in the wall. And we couldn't reach this problem, it's great if you're building adapters, but it also fails that this idea of speaking the same language doesn't work. And so that's that's my summary. Okay.
[00:35:09] And we knew this, DDD said like, great, let's go ubiquitous where we can inside the bounded context. And also private persistence create safe bubbles so that we can do great stuff in this uh in this area. And the moment we started decomposing the system well with the right boundaries, then we could do great stuff. We have a great language, triggering insight, we have the safety for a continuous evolution inside the bubble without a continuous negotiation about should I rename this table and stuff like this. No, it's it's actually great. Works very, very well. Everybody happy. And the original battle was between the canonical perspective on the shared database. This was of fighting in the DDD community or in the architectural community, no, we don't share the same database. We are in local space with local ubiquitous language and if we need to pass information, domain events are a way better idea. And progressively, looks like a lot of people said like, actually, bounded contexts are better, so let's go. I mean, I I was fighting this battle 15 years ago. And now I feel like everybody's knowing like, yes, good. So, victory. Except, we forgot at least one thing and probably two. We forgot the external users. I mean, working inside software solution inside the organization, make us forget that we had the privilege of talking with the users in an unmediated fashion, the expert and the users and the stakeholders many times were the same people. And this was creating the great background for a conversation creating ubiquitous language. In the surface language, oh, that's a different story. It's uh we also forgot business intelligence as well as another force, but that's not this conversation. The different forces on the surface language compared to the ubiquitous language are actually different. So in ubiquitous, we might go deep trying to understand all the intrigues, we might even inject new abstraction and building blocks and tweak the language of the people we are talking to. Can we do this with the users? Well, not really. I mean, we can launch new uh terms like tweet or real or TikTok, that's a possibility. But explaining stuff to users, that's not a good way to sell. So the other the thing about the language which is really different is while the ubiquitous goes in massive precision, try to capture the essence of a language, uh surface language is different. It requires the illusion of simplicity and not a deeper understanding of the mechanics. This is not what makes your product sellable. So, what happens if you if you want to see the ubiquitous to show the ubiquitous language, maybe that that's not the thing that you want to see. So, even if in the past, the moment we started having a conversation with people in the in the design world, it felt like, oh yes, we have a very similar concept. No, it's not. The forces behind bounded context in ubiquitous language are, yes, focus on the language. They are not the same forces on the surface language. And try to make them feel like it's the same, is not exactly leading you where you want to go. So, one one of the things that that we uh we had to agree, they need to ex to coexist. There's one language which needs to be optimized for user engagement and many other language that might need to be optimized for implementation. And we clearly need to keep the distance between the languages as small as possible, but we cannot reduce this distance to to zero because they have different purposes and they will be pulled in different different directions. So we cannot choose only one paradigm.
[00:39:16] The thing that happens if uh, well, let's start from the surface language. Most users think in a flat language and if we take the insights from the users and their story, we will end up with a gigantic Microsoft access or with a with a uh flat monolith that will lead to coupling by following what the users do. The users don't have to understand the complexity of bounded context. That's why they are paying for the software, not to know about this mess. Uh but we are wrong too. The moment we understand the complexity and the sophistication of the languages behind the scene, we might feel like, okay, well, let's let's put it in the user interface. Don't do this. Uh because the moment you expose all of this complexity to the users, well, that's not the tool I liked. That's not what I wanted. I I wanted something simpler and this is a mess. Like uh uh, let's say having Google calendar and instead like, oh, first you have to tell me which type of event you you are dealing with. Is this an appointment? Is this a dinner or this No, no, just just an event where to do something, something simpler. And uh users would like to have simplicity and uh we need to understand the complexity. We have different goals here.
[00:40:38] So, uh, the the other part is uh all of this ability to craft a very specific oriented language is coming because we have accessibility to the real users. And we can also force them or educate them to do something more sophisticated.
[00:41:00] A little interlude in in between, but quick. The other thing that was bugging me every time we started this discussion with uh people in the domain driven design space, we we just like asking like uh, how many people here are working on a product? Yeah, yeah, a lot of people. Yeah. And then I ask, okay, how many customers do you have? all of this ability to craft a very specific oriented language is coming because we have accessibility to the real users and we can also force them or educate them to do something more sophisticated. a little interlude in in between but quick. The other thing that was bugging me every time we started this discussion with the uh people in the domain driven design space. So we just like asking like uh how many people here are working on a product? Yeah, a lot of people. Yeah. And then I asked, okay, how many customer do you have? And uh no, and the answer was it's it's an internal product. And we don't do projects, we started using a product mindset and it's a solution that we are evolving into a product. Or we have a product that has one customer and we are going to have two quickly. All of this space is not product space. That's that's my my take on this. And if you have zero customer, you have a dream not a product. If you have one customer, you have a solution, but you're probably not doing even domain driven design. Because it's probably not important for them, it's important for you, but you don't have all the core thing. If you have many, maybe you are in chart. Then you can do quite a few other other things. If you have few customers, especially if you are in the B2B space, then you are in trouble. This this is probably the most horrible space in product land, when you have four or five customers and especially when you have one which is clearly dominating. This is what we call the Miranda anti-pattern. If you remember that devil wears Prada. And this the dominating customer might be uh let's say uh a toxic force inside your backlog because they can. They might abuse of your backlog in in very funny way and uh but they are your biggest customer. So they they can control you. Um, actually I want to skip this one.
[00:43:03] But slow. Okay. So the the the other problem here is uh is this feature only for one customer? I know it's B2B, I know it's big. But how much of my integrity is is changing? And uh and in some places this was actually referring to the the uh approach of base camp and the and the philosophy behind behind rework, like there are products which are absolutely aggressive about not being customizable. This is a product, this is what you get, don't ask me for more stuff. And uh but this is this was relevant for for me like uh what is the point of going product if we let other people decide? I mean, the the whole thing about going into the product space is about owning your own strategy, doing the thing that you think is right. Not moving from having one boss to have five bosses or a thousand of bosses. That that's totally not the point. So how much are we leading, doing what they are telling us to do, not what you want to be upstream. This is where I would like to be. But product thinking implies taking responsibilities. The victim of this process is actually what I think is the the other important thing to talk about, which is the idea of design integrity. So, um, this this is this I was listening to to Sander this this morning and said everybody has technical debt. And I was not quick enough. I really wanted to say no. I wanted to be the only one in the room saying no, uh because uh because actually I I don't
[00:44:51] I don't have the feeling of having a debt, but also I don't like the assumption that everybody has some debt to pay. Maybe it's a very Catholic thing, or uh I I don't even know where this is coming from. But it looks like there's a burden that every software development team has to has to pay. And I think it's not a good metaphor. Uh for many reasons, I I wrote a blog post uh about it a few months ago and uh and I think I think I I made a point there. But uh one of the thing is if we talk about the depth. a lot of the discussion goes into, oh wow, but we did it, it was an investment, it didn't pay off and we have to repay it and blah blah blah. And then we end up trying to explain the concept of technical debt to our business stakeholders. All of this is waste. There it's not their problem, it's something that we have to deal with, but it's also, yeah, humiliating sometimes and use, can we put a refractory story in our backlog? No, that that is the wrong discussion, I don't, I mean, it makes me feel bad when I'm when I'm when I'm saying this. The approach I like is uh is is flipping the coin. It's probably exactly the same thing with a different name, but I like the idea of design integrity. What is design integrity? It just how much the current design fits the current purpose. So, Italians, stereotypes. This is a pizza, has a, yeah, I would say just fit in the purpose also same size of of of the plate. So good starting point. This is clearly having some problems with design integrity. What is my point here? If this is the best you can do, you should probably quit your job. Or it could happen only once, then you have to fix it and make sure what you are delivering to your customers is the best quality you can afford, the best quality point you can settle on. If you have, if you know that at the same price you could have a better taste with different ingredients, well, you should use them, no reason not to. There is no reason at all to craft an inferior product if you know how to do it. And this is what you should do with with products, like, oh, there was no time. There was no time to cook the pizza. Come on, well, in this case it was too much time to cook the pizza. But that is not the point. It's it's a matter of ethic in some ways. And this is a different design uh approach to the same problem that might be comparable. Round pizza is optimized for sitting, if you heat it out, eat it hot is better. Square pizza is optimized for walking and could be kept warm for a longer time and uh it's a different product, different market segment. They both good. Except if we get request like we want a calzone by the end of the next week, we might have a problem. Because with the run pizza is very easy to flip it, fold it inside the calzone. While with a square pizza, good luck to make a one meter long calzone, that's not exactly where it should be. Okay. So this is actually one point that is making a lot of people feel dizzy, but maybe because they are not where they should be. And this is where I would like to be instead, I've been using Bruce Lee pictures quite a lot, and in this case, even if I don't know much about martial arts. My point is, my design should be in the best possible position, the the readiness position in many martial arts is the one that gives you most option to react to an unpredictable attack. And this is where where you want to be. You don't want to start to fight in this position, you already lost. You don't want to start with that technical depth. You would like to be exactly in the most likely position to catch the the highest number of opportunities. Okay, that's exactly where I want my code to be. So, if your but if your model matches the understanding of your domain, if you have no gap between your perception and implementation, this is probably your best position. You're in the best possible place to respond to change. And the hypothesis I have, if you are there, and you have a fit model, and you add one feature, then you end up with another fit model. I mean, it doesn't take much. It's very hard to be there, the moment you are there, one attack and I get back in the ready position, another attack, I'm back in the ready position.
[00:49:35] I'm exactly where I should be. If I keep dragging my technical debt, I'm hopeless. So many products, it's a feeling, not strong data, are in a place are successful, only because your competitors are slightly worse. Said.
[00:49:55] But the other thing is many times you feel like you're walking in the mud. moving, these people are actually doing it for for for fun. But I've seen many many software development teams uh exactly there without realizing that, well, there was a highway going from this city to this one and we couldn't we couldn't make it. And uh but it's very hard to see the highway if you keep walking in the mud. So, oh yes, but we still have all of this technical debt to carry. No, there's a road nearby.
[00:50:32] Second problem here is uh we would like to be ready, but we don't know what we should be ready for. And uh and there's a lot of misconceptions who once again it depends. There's places where there's a clear road map about this is what you would like to do in the next in the next five years and uh that might be a rabbit hole in terms of fragility. Uh if we do nothing, we have to be ready for everything, this is where your architects tend over design adding in direction layers because maybe customer would ask for this this stuff. They have no idea. They're totally getting ready for alien invasions or anything like this. But there is something in between, is not black and white. is uh relatively predictable.
[00:51:24] Uh but what we need badly is if we need to be ready for something, we need to understand what this something might be. And so segregation once again becomes a problem. We can't catch all the possible verbs just because people mentioned that. And also we cannot feel guilty for not catching all the verbs. The thing is, can we predict this future or not? My perception here, once again, not exactly data, but the perception is, you really have a lot of information about what the likely future might be. You can still have black swans event. You can you could have something like uh pandemic disrupting everything and moving everything uh remote or chat GBT changing the world apparently. But a lot of stuff is already in our radar. So you shouldn't be that surprised.
[00:52:20] And uh the other thing is, even if we could predict, we would never ever any way have the um uh force or the uh possibility to catch all the possible opportunity. So, once again, it it pulls again into the what what the product triad like you need not to be driven by uh marketing, business and so on. Engineering has design integrity in place. Uh just just to say like, well, we are not fit for a calzone, this opportunity is not going to be taken.
[00:53:04] Right. Okay. So saying no is a possibility not in my name. And uh the other thing that I like is design integrity is uh is it hard to build and very easy to destroy? It takes very little. We already mentioned this, so I could go a little faster here. Uh the other the other thing that is that was relevant in in many places was how much good architecture was providing optionality. The idea of bounded context of multiple bounded context, each one with a specific purpose, turn out to be a pretty good predictor of the possibility of change happening in only one bubble. So, even if change was not completely predictable, we could still minimize the impact because it was predictably happening inside the bubble. One big exception, GDPR, everything else was a lot more predictable. So, one possibility quickly was to, okay, we have this new idea for a possible new feature, where is it gonna fit? Is it gonna fit in our bubble? Should we extend our model, should we create a new model for the new stuff, should we make an external model for this? Very quick questions, uh, yeah, I wanted to mention this, but uh not enough time to uh to drill into that. In terms of implementation, last thing is uh domain driven design, it cares the attention into robustness, into little building blocks. And uh and it really feels with with the idea of still cooking and having a very very clean desk. And uh it means building and sharpening your tools. Not there is no reason to be messy, there is no reason to be in a in a restaurant or in a pizza place and ask every single day, where is the oregano, where is the pepper? You should know, you've been here, it should be tidy, oops, and be in the right place. And uh so the building blocks mostly value object but not only, turn out to be a good place to build the robustness, the composability, the and to erode the complexity of the system and get people ready to experiment. Yep. Time to close.
[00:55:28] So, I guess, I guess I convey the the feeling of, okay, this was a big rabbit hole. There's a lot of stuff. I hope I could provide a couple of insights. Number one, dogmatism and tribalism, forget about it. It just uh try to collaborate with people, bring the background of some ideas, not all the ideas are guaranteed to work. Design integrity, I think is probably the most important thing. Like uh it gives you option, it gives you safety, it gives you time to participate in the deeper discussion. And uh make make it a key requirement, you cannot go product carrying the burden of we still have rats in the kitchen. That's not part of the cards.
[00:56:14] You don't need the DDD architecture for every type of product, I mean Excel goes on a file system. You don't need a database and then some so there's variation. But good sophisticated architecture implementation gives you data and options. But the most important thing is breaking the barriers between the disciplines. This is massive waste. We are we are talking with our local jargon and we're not getting where we are going. So make the pictures available, uh make the conversation simpler and find ways to learn from the other disciplines and and collaborate.
[00:56:51] And I would say the most important thing is the final one. Can do this alone, so we need help and collaboration. And uh well, three rabbits are probably better than one. So, thank you and sorry for stealing the last two minutes. I'm going to be around for uh today and tomorrow. So any question uh thank you.

Transcript