Excellent talk! I've been familliar with CQRS and some DDD, but how you explained event storming really makes me equipped to tackle even larger projects! Thanks!
First of all, IMO, Twitter is not a good example to explain DDD. Twitter's architectural and technical challenges are less about DDD. When reading about DDD. I can only relate it to developing medium to large-scale business information systems in the monolithic application (pre-microservices) era. (I have separate opinions on using DDD for those contexts. Basically, I'm not a fan.) I don't think those who suppose to rewrite Twitter will/should approach this way at all. Applications like Twitter have a unique set of technical and architectural challenges only a minority of the systems share. That's why this scale of companies develop their own middleware, database systems, etc. The architectural approach taken in this talk has not addressed matters like how the technology landscape changes if Twitter capped to 10,000 users vs 2 billion users. Treatments of those factors cannot be postponed at all. Elon has dived deeper into Twitter's technical details/challenges to a surprisingly deeper level as a CEO. And his understanding of the issues is quite agreeable. ruclips.net/video/FkNkSQ42jg4/видео.html This is one of the best critics of DDD which I came across: ruclips.net/video/ZZp9RQEGeqQ/видео.html P.S. My comment is opinionated. I truly appreciate the speaker's effort. His ideas very well go with the mainstream of the software development industry (at least as I've witnessed it). I consider myself a contrarian.
correct, as far as i know ddd is about complicated enterprise business logic, and twitter is about highload, enterprise is not always equal highload, and highload is not always equal enterprise, and it is twitter case
Wonderful talk! Only thing I didn't quite understand at first was the List-Timeline-entry example. I initially thought the proposal was to treat the entry as its own small *entity* within the list-timeline *aggregate* and thought "yes". In a normalized relational representation, either the rows for the entries will have a listId field or there will be an association-table (preferable a listId field since there is an exclusive ownership-relation from list-timelines to entries, but for technical reasons a table might sometimes be preferable). Only after going back after the "nay" did I realize it said "aggregate", not "entity". In any case - once we create a consistency/transactional boundary for the list that encompasses managing list-entries, you have the Entry as a entity in the List-Timeline aggregate - thus you have separate entry-ids and tweet-ids (plus, here also a "type" field indicating it is supposed to eventually hold more things than just tweets, though then "tweetId" is a very specific field that might be generalized to "entityId", which should induce a renaming of "type" to "entityType", which might then even contain a FQDN). This means that the processes which manage list-entries (and should be contained in the Aggregate aside from pure persistence aspects) always need to check for existence of an entry belonging to the list which has the same type and id of the related entity. If everything is set up so that list-entries are only fetched and written within the context of a list, the objects representing the entries in memory don't need a "listId" field, and can live exclusively within the lifetime and ownership of the list. But in a relational database with a normalized schema, either the corresponding rows would have a "listId" field, or there would be an association-table. An alternative would be a document database - dropping the normalization requirement removes the impedance between in-memory schema and persisted schema - though this brings us to the question of mapping between write- and read-models, which is a slightly bigger issue :)
Really nice talk Amichai! Just wanted to ask you why you presented all aggregates/constraints in event storming as systems even if they were not external. Was it in order to be simpler since aggregates are represented after that part of the talk?
I bet that this will fail. Rewrites are, 99% of the time, a poor decision, especially in cases like Twitter where many people have already left. I am certain that there are significant parts of the codebase that no one understands, which exacerbates the situation DDD is also ill-suited for a straightforward product like Twitter. Most developers could create a Twitter clone within a week; the real challenge lies in making it fast and scalable, and DDD doesn't contribute to that.
DDD is helping to avoid the rewrites of the whole system, due to poor initial design or no design which happens when you create such a system in a week, or so. So it helps manage complexity and give the ability for extendable and maintainable system, which can last in time and be able to add features in the same pace as when you started it. Performance is a key non functional requirement which can be added in the design as well as by infrastructure technology choices. Clean Architecture used makes the code testable in order to catch bugs continuously as the system grows. Avoiding devs to spend half their time finding and solving bugs by reducing this time significantly.
Moreover since as you said a twitter clone could be created by a developer in a week and the only problem is performance, this will mean that the actual twitter app is throwing a lot of money for having more than one developers. So let's say you need one developer to maintain this project he wrote in a week, and let say, 5 of them to just work on infrastructure and performance optimizations. So with the setting you presented, more than 6 devs for Twitter would definitely be a waste of money. So is this really true; Does twitter just waste money in their devs?
Everything is subjective till you see the code and actual architecture. Also rewrites are all about scaling and problem solving rather than defining already identified domain and its problems. The high-level talks don't make sense until you actually start working on it and figure out that things aren't fancy as they seem on paper. Practicality also matters and many large organisations have just too many opinions coming from within and from outside influencing decisions that may or may not work.
@@MaulikParmar210 I agree definitely that the initial design would definitely be the final since this is an evolutionary process to take educated decisions. The problem is the lack of such processes when creating a new software system. There should be some kind of approach of exploring the business rules as well as organising the modules of your system. Scalability is fully aligned with DDD concepts since the modules of your system would communicate mostly via a broker system via domain events. You can initially create a modular monolith with bounded contexts as modules. Then you can gradually remove modules from the monolith and deploy them as microservices. Then you could even split a module even further at the scale of an aggregate as a microservice if needed. So scalability is a different concern, but matches perfectly with the DDD contexts, avoiding distributed monolith antipattern.
@@antoniss5423 > Does twitter just waste money in their devs? Well, Elon has already proven that to be true by firing 99% of the team while keeping the ship afloat, right?😂 I have two decades of experience working with both startups and large companies. You might be surprised by how much a small team of highly skilled and motivated developers can achieve if they focus on simplicity and getting things done. Instagram had a team of only 19 people when it was bought by Facebook. In my previous company, we built the entire system with just 6 guys. Our system became the top logistic system in Europe for its category. We didn't employ DDD, Scrum, meetings, or anything else. That company later artificially inflated to over 200 people as the owners were trying to go for an IPO and get a higher valuation, so I left. In my current job, at a bank, the system was designed by following DDD, event-driven approaches, and other buzzwords. It's a massive, over-engineered mess of 30 microservices that require 60 developers to maintain. It's impossible to run locally and no one fully understands it. Myself and some other like-minded individuals refactored 80% of its services into a single service during a hackathon. The service turned out to be a mere 3k LOC Django app 😂. We won the hackathon and made a few enemies.
Ooh it’s out! This was my first international conference so I’m excited to hear your feedback and how i can improve 🙏🏼
Excellent talk! I've been familliar with CQRS and some DDD, but how you explained event storming really makes me equipped to tackle even larger projects! Thanks!
Maybe dial back the Elon fawning like, 99%
@@SeanYeomans71urgh. You made me spit out my coffee
Wow, this is rare. Starts with a bigger picture and then drills down. God Bless You More and you give more such great presentations.😊
First of all, IMO, Twitter is not a good example to explain DDD. Twitter's architectural and technical challenges are less about DDD. When reading about DDD. I can only relate it to developing medium to large-scale business information systems in the monolithic application (pre-microservices) era. (I have separate opinions on using DDD for those contexts. Basically, I'm not a fan.)
I don't think those who suppose to rewrite Twitter will/should approach this way at all. Applications like Twitter have a unique set of technical and architectural challenges only a minority of the systems share. That's why this scale of companies develop their own middleware, database systems, etc.
The architectural approach taken in this talk has not addressed matters like how the technology landscape changes if Twitter capped to 10,000 users vs 2 billion users. Treatments of those factors cannot be postponed at all.
Elon has dived deeper into Twitter's technical details/challenges to a surprisingly deeper level as a CEO. And his understanding of the issues is quite agreeable. ruclips.net/video/FkNkSQ42jg4/видео.html
This is one of the best critics of DDD which I came across:
ruclips.net/video/ZZp9RQEGeqQ/видео.html
P.S. My comment is opinionated. I truly appreciate the speaker's effort. His ideas very well go with the mainstream of the software development industry (at least as I've witnessed it). I consider myself a contrarian.
correct, as far as i know ddd is about complicated enterprise business logic, and twitter is about highload, enterprise is not always equal highload, and highload is not always equal enterprise, and it is twitter case
Wonderful talk! Only thing I didn't quite understand at first was the List-Timeline-entry example. I initially thought the proposal was to treat the entry as its own small *entity* within the list-timeline *aggregate* and thought "yes". In a normalized relational representation, either the rows for the entries will have a listId field or there will be an association-table (preferable a listId field since there is an exclusive ownership-relation from list-timelines to entries, but for technical reasons a table might sometimes be preferable). Only after going back after the "nay" did I realize it said "aggregate", not "entity".
In any case - once we create a consistency/transactional boundary for the list that encompasses managing list-entries, you have the Entry as a entity in the List-Timeline aggregate - thus you have separate entry-ids and tweet-ids (plus, here also a "type" field indicating it is supposed to eventually hold more things than just tweets, though then "tweetId" is a very specific field that might be generalized to "entityId", which should induce a renaming of "type" to "entityType", which might then even contain a FQDN).
This means that the processes which manage list-entries (and should be contained in the Aggregate aside from pure persistence aspects) always need to check for existence of an entry belonging to the list which has the same type and id of the related entity. If everything is set up so that list-entries are only fetched and written within the context of a list, the objects representing the entries in memory don't need a "listId" field, and can live exclusively within the lifetime and ownership of the list.
But in a relational database with a normalized schema, either the corresponding rows would have a "listId" field, or there would be an association-table.
An alternative would be a document database - dropping the normalization requirement removes the impedance between in-memory schema and persisted schema - though this brings us to the question of mapping between write- and read-models, which is a slightly bigger issue :)
Really nice talk Amichai! Just wanted to ask you why you presented all aggregates/constraints in event storming as systems even if they were not external. Was it in order to be simpler since aggregates are represented after that part of the talk?
oh my god did Elon Musk threaten to fire you if you didn't fill the presentation with his photos or something? impossible to watch
I tried watching this but the amount of elon throating was intolerable
Same
One year ago if you told me I'd be at a tech conference I'd call you a liar
Number of likes 404. Let fix that
Very unorganised and annoying to follow. There's plenty of better talks on the topic out there, don't waste your time on this one.
I bet that this will fail. Rewrites are, 99% of the time, a poor decision, especially in cases like Twitter where many people have already left. I am certain that there are significant parts of the codebase that no one understands, which exacerbates the situation
DDD is also ill-suited for a straightforward product like Twitter. Most developers could create a Twitter clone within a week; the real challenge lies in making it fast and scalable, and DDD doesn't contribute to that.
DDD is helping to avoid the rewrites of the whole system, due to poor initial design or no design which happens when you create such a system in a week, or so. So it helps manage complexity and give the ability for extendable and maintainable system, which can last in time and be able to add features in the same pace as when you started it. Performance is a key non functional requirement which can be added in the design as well as by infrastructure technology choices. Clean Architecture used makes the code testable in order to catch bugs continuously as the system grows. Avoiding devs to spend half their time finding and solving bugs by reducing this time significantly.
Moreover since as you said a twitter clone could be created by a developer in a week and the only problem is performance, this will mean that the actual twitter app is throwing a lot of money for having more than one developers. So let's say you need one developer to maintain this project he wrote in a week, and let say, 5 of them to just work on infrastructure and performance optimizations. So with the setting you presented, more than 6 devs for Twitter would definitely be a waste of money. So is this really true; Does twitter just waste money in their devs?
Everything is subjective till you see the code and actual architecture. Also rewrites are all about scaling and problem solving rather than defining already identified domain and its problems.
The high-level talks don't make sense until you actually start working on it and figure out that things aren't fancy as they seem on paper. Practicality also matters and many large organisations have just too many opinions coming from within and from outside influencing decisions that may or may not work.
@@MaulikParmar210 I agree definitely that the initial design would definitely be the final since this is an evolutionary process to take educated decisions. The problem is the lack of such processes when creating a new software system. There should be some kind of approach of exploring the business rules as well as organising the modules of your system. Scalability is fully aligned with DDD concepts since the modules of your system would communicate mostly via a broker system via domain events. You can initially create a modular monolith with bounded contexts as modules. Then you can gradually remove modules from the monolith and deploy them as microservices. Then you could even split a module even further at the scale of an aggregate as a microservice if needed. So scalability is a different concern, but matches perfectly with the DDD contexts, avoiding distributed monolith antipattern.
@@antoniss5423 > Does twitter just waste money in their devs?
Well, Elon has already proven that to be true by firing 99% of the team while keeping the ship afloat, right?😂
I have two decades of experience working with both startups and large companies. You might be surprised by how much a small team of highly skilled and motivated developers can achieve if they focus on simplicity and getting things done. Instagram had a team of only 19 people when it was bought by Facebook. In my previous company, we built the entire system with just 6 guys. Our system became the top logistic system in Europe for its category. We didn't employ DDD, Scrum, meetings, or anything else. That company later artificially inflated to over 200 people as the owners were trying to go for an IPO and get a higher valuation, so I left.
In my current job, at a bank, the system was designed by following DDD, event-driven approaches, and other buzzwords. It's a massive, over-engineered mess of 30 microservices that require 60 developers to maintain. It's impossible to run locally and no one fully understands it. Myself and some other like-minded individuals refactored 80% of its services into a single service during a hackathon. The service turned out to be a mere 3k LOC Django app 😂. We won the hackathon and made a few enemies.
Quite awful