This is fantastic. Great explanation. I've seen this explained elsewhere in a book I think and for the life of me can't remember which but this is an excellent summary.
I was once in a project where I was forced to implement an architecture that is totally different to the team structure. it was a nightmare while the startup founder CTO lives in his ivory tower
I've been binge watching all your videos. Great stuff, I already knew some of this stuff but these are still really really clear and concise descriptions and you've had a thing or two to teach me too. This one's my favourite though. I'm mad keen on spoken language too and all your talk of tenses and moods and persons ticks two of my boxes at once. :)
Excellent! I've never really worked on any systems where Eventual Consistency is a thing... and I've, obviously, heard the term bandied about a lot... but never really known how it works.... until now! :)
Best explanation with short videos. I really like it. Understood well about DDD.. Please post a video related AWS migration from off-premises to ON premises for legacy application ex: Java application
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
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 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.
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.
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.
