Rebuilding Twitter Following Clean Architecture and Domain-Driven Design - Amichai Mantinband

This conference session will delve into rebuilding Twitter using clean architecture and domain-driven design principles. Specifically, we will cover the following steps:

1. Event storming: We will discuss the importance of event storming in understanding the business requirements and user needs for the new Twitter platform.
2. Bounded contexts: We will identify the bounded contexts within the Twitter system, breaking down the system into smaller, self-contained modules.
3. Aggregates: We will identify the aggregates within each context, improving performance and ensuring consistent data updates.
4. System folder structure: We will discuss the system folder structure and how it should be organized according to clean architecture and domain-driven design principles.

By the end of this session, attendees will have a taste of how to build projects from scratch using clean architecture and domain-driven design principles.

More of Amichai Mantinband here:
@amantinband

Check out our new channel:
NDC Clips:
@ndcclips

Check out more of our featured speakers and talks at

[amantinband]

Ooh it’s out! This was my first international conference so I’m excited to hear your feedback and how i can improve 🙏🏼

[manawardhana]

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.


This is one of the best critics of DDD which I came across:


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.

[sujeetbadnale]

Wow, this is rare. Starts with a bigger picture and then drills down. God Bless You More and you give more such great presentations.😊

[antoniss]

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?

[DodaGarcia]

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

[DumblyDorr]

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 :)

[SeanYeomans]

I tried watching this but the amount of elon throating was intolerable

[FredWheezy]

One year ago if you told me I'd be at a tech conference I'd call you a liar

[afailable]

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.

[Trooper]

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.