- 10
- 184 440
Drawing Boxes
United Kingdom
Registrace 2. 05. 2022
Software design, architecture and coding concepts explained in short animated presentations.
- Original background music recorded and produced by myself.
- Twemoji graphics made by Twitter and other contributors, licensed under CC-BY 4.0.
- Original background music recorded and produced by myself.
- Twemoji graphics made by Twitter and other contributors, licensed under CC-BY 4.0.
Agile Manifesto: What Agile development is really about
The original Agile Manifesto lays out 4 simple values:
0:00 Intro
0:30 Responding to change over following a plan
2:02 Customer collaboration over contract negotiation
3:23 Working software over comprehensive documentation
4:38 Individuals and interactions over processes and tools
5:25 Conway's Law
agilemanifesto.org/
0:00 Intro
0:30 Responding to change over following a plan
2:02 Customer collaboration over contract negotiation
3:23 Working software over comprehensive documentation
4:38 Individuals and interactions over processes and tools
5:25 Conway's Law
agilemanifesto.org/
zhlédnutí: 919
Video
Events vs Commands: What's the difference?
zhlédnutí 2,4KPřed 5 měsíci
Message bus communication often uses Commands and Events. But, what's the difference between them? Aren't they both just messages? The difference is about grammar, intention, and also the direction of some different kinds of arrows... 0:00 Intro 0:18 What do the words mean? 0:34 When do they happen? 1:36 Who are they for? 2:53 Direction of control and dependency 4:19 Example third party provide...
Outbox Pattern: Fixing event failures in an event-driven architecture
zhlédnutí 4,7KPřed 6 měsíci
The Transactional Outbox Pattern ensures a message is always published to a message broker when making changes to a database, even if the message broker fails initially. This is essential for event-driven architecture to ensure consistency when other services are rebuilding state from your events. 0:00 Network failures 0:54 Atomic Transactions 2:00 Publishing the event 2:52 At-Least Once delive...
Conway’s Law: Why your architecture looks like your team structure
zhlédnutí 4,9KPřed 8 měsíci
The communication structures in your organisation influence your software architecture. We explore some examples of this and explain how it relates to Domain-Driven Design (DDD) and Microservices. 0:00 Definition 0:31 Layered teams example 2:04 Lifecycle teams example 3:07 Cross-functional teams & DDD 4:22 Inverse Conway Manoeuvre Conway's Law: www.melconway.com/Home/Conways_Law.html Inverse Ma...
Event Sourcing Explained
zhlédnutí 18KPřed rokem
What is Event Sourcing? Is it anything to do with CQRS and DDD? We explain the pros and cons compared to traditionally updating the current state in a database. We cover trade-offs with Eventual Consistency, problems with concurrency, and options to solve those with optimistic concurrency techniques. 0:00 Intro 0:40 Deleting 0:57 Analytics & Metrics 1:23 Concurrency 2:24 Calculating State 3:26 ...
Microservices vs Monolithic Architecture
zhlédnutí 13KPřed rokem
Microservices, a Modular Monolith, or a Big Ball of Mud. This video explains the pros and cons of choosing a distributed system over one big monolith (whether that's a nicely structured Modular Monolith, or just a jumble of spaghetti code). 00:00 Definition of Microservices 00:14 Monoliths 00:35 Big Ball of Mud 00:52 Modules 01:30 Microservices 02:17 Network Communication 02:59 Distributed Ball...
DDD Bounded Contexts & Subdomains
zhlédnutí 31KPřed rokem
Bounded Contexts, subdomains and strategic design from Domain-Driven Design explained. 0:00 Complex Systems 0:26 Ambiguous Language 1:26 Separating Contexts 2:06 Context Map 2:22 Types of Subdomains 3:11 Integrating Between Contexts
DDD Building Blocks
zhlédnutí 34KPřed rokem
Explaining Aggregate Roots, Domain Events, Entities, Value Objects and Repositories - the building blocks in Domain-Driven Design. 0:00 Building Blocks 0:18 Ubiquitous Language 0:54 Value Objects 1:41 Entities 2:22 Domain Events 2:51 Aggregates 3:39 Repositories
CQS and CQRS: Command Query Responsibility Segregation
zhlédnutí 22KPřed rokem
The CQS and CQRS design principles explained. 00:00 CQS: Command Query Separation 01:29 CQRS: Command Query Responsibility Segregation 2:10 Separating reads and writes 2:37 Scaling independently
Hexagonal, Onion & Clean Architecture
zhlédnutí 54KPřed 2 lety
Three similar software architectures explained. 00:00 N-Tier Inversion 01:04 Hexagonal Architecture 01:50 Onion Architecture 02:58 Clean Architecture Hexagonal Architecture - alistair.cockburn.us/hexagonal-architecture/ Onion Architecture - jeffreypalermo.com/2008/07/the-onion-architecture-part-1/ Clean Architecture - blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
Your Videos containing explanations in few minutes what workshops trying to say in hours. Thank you very much! Keep up! I will share it within my Team :)😊
Up! I appreciate videos like these because Agile has been abused by quickly trained Agile coaches with no real knowledge of IT. They are enforcing practices they don't understand, making teams miserable and ineffective, eventually making people completely turn away from Agile I'm not a fan of the whole commercialised thing, but it's clear that the core values make sense
Love your explanation thank you - I'm still on the fence about this paradigm. Again it feels like it was put together by some journeymen devs who were bored and felt they needed to invent something nobody asked for and probably another layer of bloat in microservice hell architecture. We developers often cite how complicated web development has become and its because of things like this.
Thanks! Glad you like it. I think in some cases you could argue that CRUD adds a layer of bloat to things that naturally have separate read and write models. But yes, using CQRS where it is not a good fit just unnecessarily complicates things
Please take a look at spring modulith, it implements all the concepts you described in all your videos !
czcams.com/users/shortsBZxSDkVcwhU?si=HkQ2Ly-GnzI66pnE
For our new system I actually implemented an event-sourced system backed by SQL using efcore; it's typed, uses automatic JSON versioning and upgrade-on-read, as well as a strongly-consistent projections system where the projection state goes in the same transaction as the event append. Performance has actually been pretty great, and the way it makes rearranging the read model as requirements change has been absolutely amazing, I don't think I'd want to go back to a regular ORM.
Isn't Value Object a bit of an oxymoron, since objects usually have identity in OO? My brain wants to call them Value Types. They behave more like value types such as int and enum, and I also think they are easier to implement as structs rather than classes in C#.
One reason to call them value OBJECT instead of TYPE, is that it is like an attribute of an entity. These attributes can also be simple or complex (=> object) but the important thing as the video also says is that it has to be immutable. For sure, simple attributes could be handled in structs or enums but the more complex it gets, the easier it is to implement it in a class. And in OO an object can literally be anything, either simple or complex. It is not a usual thing to have id in an object, thats more like an entity.
I can't believe how clearly this video explains everything. It's the best comprehensive explanation I've had in a while.
Excellent video displayed in an animation, thanks a lot
Its most underrated channel. Thanks for good explanation. I request you one think please avoid music. Your explanation is very important cor viewers.
I really like your videos, they explain everything clearly, though I have a little bit of a different opinion here regarding monolith. Yes it is frequently become a "spaghetti jungle" what I'v seen in many companies I worked for, but I think there are use cases where the monolith application is the preferable choice considering the expected scalability, deployment and cost. The business scenario and so on. It this case a monolith application should be built in a clear and modular way following best practices, separation of concerns, business logic, therefore it will be easy to maintain, and the code in a properly structured monolith can be easy to follow, modify. If it is done in a proper modular way, there is a way to split it up later in that unlikely scenario that it has to be ported to a micro-service architecture. I am saying "unlikely" because before making the decision of the right architecture I assume it was assessed properly which solution fits the business case.
Yup, spot on! There are always trade-offs to consider. Sometimes a modular monolith is exactly the way to go
You just earned a sub! Awesome explanation mate
Amazing video!! 👏
This is fine for atomic streams of operations that don't conflict received in order. Like 80% of website style transaction. However it does NOT scale horizontally. It provides, no, it refuses basic concurrency monitor controls and basics like "Test and set". Splitting a "Dequeue" operation into 2 concurrent/ordered operations leaves you wide open to race conditions, dead locks and I cannot see how this scales horizontally to accomodate increasing loads.
You deserve a lot more views and subscribers. Love how clear you explain things.
I have never faced the "hexagonal architecture" wording in my 11-years career
This is also somewhat i figured. Thanks for clarifying everything 👌
Great explanation, thank you!
an undervalued video with amazing explanation of so sophisticated topic. мое почтение
amazing video!
Thanks for your great content!
great video, thanks!
best
perfect♥
Well, not quite. Teams do not decide on cross domain integration and interactions. Architects do.
Architects themselves are part of the communication structures too, and what they build/create (frameworks, documentation, etc) is part of the system
Ok, this has its cons. It is twice slower, because we need to do two additional DB operations which are slow. Second, don't deleta data from status table. Mark it as processed instead. This will keep tracking and reduce the possibility of double send.
Yup - there are always trade-offs! If performance is more important than guaranteeing message delivery in your system then you can just do both in parallel and accept that there could be inconsistencies. I like the idea of marking as processed instead hard deleting from the outbox. Trade-off there is with storage space. Maybe a retention period can hard delete them after a few days/months
what if you have huge data like 100000000comments in Post object. I don't think you can init a domain object with that much... looks useless to me when dealing with large chunks of data. Thoughts?
That's a great example. There's a bit of an art to defining the aggregate boundary, and I think yes you want to try keep them smaller than that. Does your domain need the full comments list to be consistent? If two users load the page, then both leave a comment, should the second comment fail with some concurrency error? Or just allow both comments? Perhaps the boundary is around the comment, not the post. But if you do, your implementation doesn't have to load every comment into memory to know if something has changed. Checking a LastCommentDate or LastUpdateDate could also work.
the ending is superb
exceptional well explained!
What toolset are you using to create these great videos? I supposed PowerPoint is one of them.
Exactly - export slides as video, record my voice and make background music in Ableton, then retime the video to the audio with DaVinci Resolve
رائع .... حقيقي رائع !
I can't believe it. Best explanation ever.
This content for free? You are a blessing to humanity, mate. It has really removed many grey areas to my understanding of the topic. Thank you!
Yup! There's Patreon for those who want to donate, but otherwise, free! You're very welcome - glad I can help
insane explanation thanks alot
At first glance I was thinking "Oh, drawing boxes is branching out from the technical videos of software engineering" The more I work in enterprise software development, the more I realize how important it is to also understand how you can work as knowledge worker in a team and how to communicate and plan even outside of it, so this video feels very much connected to the other content on this channel. Thank you!
Exactly! It's a bit different from my other videos, sure, but this kind of stuff is just as important. You're very welcome!
holy shit thats what a clear explanation is!
What an absolutely fantastic material!! Thanks a lot for this :)
honestly, your are very underrated :/ Your are helping me alot with these videos! Thanks !
Thanks! Very glad I can help
It is very well explained, but I'm missing domain services. Quoting Evans: "Sometimes, it just isn’t a thing.".
Thanks! Aaaah yes - I'll add that to my list of potential future videos :)
Excellent explanation! Visual, concise but still explaining all the important matters.
that last slide is confusing. how is callback related to ES?
Those bits are unrelated. The link to ES is really just for those that might be learning about "events" in software engineering more generally, that's all. Apologies for the confusion!
Why does this channel only have less than 5k subscribers? Should be at least 100k... 🔺
<3 I appreciate it, thank you!
Need video for Unit of Work pls
Added to my list!
I'm happy to be learning English and being able to enjoy incredible content like this! Thank you very much for sharing your knowledge, you have many skills! Congratulations on your genius. For the good of humanity, please continue.
Sabia que era BR. Caraca, impressionante a explicação sobre as arquiteturas.
Crisp and clear, leaving no doubts or unanswered ifs. Great job. Draw us more boxes.
Nice!
thanks man, you are awesome!
you are awesome and so are your videos !!!
Waiting for so long😊
Hehe, thanks for waiting! A lot of time goes into these videos - hopefully I'll get faster one day
very difficult to understand, still can't get the point