Thanks!

DDD defines that the single instance of a single aggregate is updated atomically. That definition is aligned with what most document databases promise, i.e. they guarantee writing a single document atomically and usually nothing more.

Those are very useful in complex systems design. I warmly suggest you read the DDD book by Eric Evans.

Eric Evans' book is great, but everywhere I've worked treat developers like code-zombies who are not allowed to talk to the stake-holders and the real domain experts whereas Evans' book rightly and correctly says not to treat us like dumb coders. What usually happens in the real world is that the stake-holders give explanations to some business analyst who explains it to a software manager who then gives us instructions which we are supposed to blindly execute. The problem is that the instructions can be interpreted in many ways and often times, asking questions leads to more confusion. What ends up happening is that the BA has one concept of the domain, the project analyst thinks of it differently, the QA has a different interpretation and says there is a defect where the developer saw it as correct, and the manager is angry that the task goes over the sprint time and says it must be because you're a slow developer (ignoring the details of what happened). Then you have to address that defect while working on the next sprint. Eric Evan's DDD (like the agile methodology) has been made rigid, regimented, conquered by upper management who want use it to incorrectly measure progress and velocity, and dogmatic. We're not allowed to talk to the stake holders, we get ambiguous instructions, there's no document clearly explaining the model, there is no reference to a ubiquitous language, etc. No, there's just domain objects, aggregates, etc. that are found only in code. DDD and Agile were great ideas but no one does them correctly and they've been made mechanical like developers are just parts of a code assembly line machinery. @@zoran-horvat

@@user-nw8oi9vn9y I am very well aware of the things you have explained here. The business analyst idea, along with rate releases and feedback organized around bug reports is the old way of doing things, ridden with issues.

That is pretty much the same thing in my opinion. The only meaningful difference is that factory methods are - methods, and as such they are assignable to delegates. You cannot assign a constructor to a delegate because it is not a method.

@@zoran-horvat Thanks!

The new course I am working on is the continuation of the Beginning OOP with C#. It will convert the most important design and coding principles when using C# to design a domain model, structures, and algorithms.

Actually, no. MediatR is a good choice.

On this point, you should watch David Comartin's videos on the outbox pattern. We implement it with MassTransit. It is absolutely necessary for Integration Events (i.e. the ones that cross bounded contexts) and... mostly necessary for Domain Events (i.e. within the same bounded context). I say "mostly" because you may have (rare) cases where you don't need guaranteed delivery of a Domain Event, although I would suggest using the outbox pattern by default even within your bounded context.

That depends on the problem you are solving but also on what you consider important in that problem. There is no single design strategy that solves all problems.

That was my reaction, too, when I first learned about that idea from the DDD book. My whole life passed before my eyes as I saw innumerable occasions where I had an explosion in the number of ways to materialize models from the database only because there were many ways to mutate them. Now, with the aggregates idea, we sustain a certain drop in performance by always materializing the entire aggregate, even in operations that only affect a small portion of it. But then a dozen carefully crafted sets of methods that used to mutate the state in the database suddenly become only one method! The simplifying effect on code is so dramatic that I never looked back after I learned this technique.

I feel so related with this description. Once I started to use Aggregates, even as you mentions to change a small portion, everything became so clear and smooth