can you please share link of guide/tutorial/content related to this stuff ,specially kafka in micro services etc

dnvriend does it make sense to learn scala? I've heard great things. I am a Java dev

It is my opinion that it is always good to learn new things but in the case of creating applications that are modeled using DDD, Scala in combination with Akka makes it very easy to create highly scalable applications for the JVM. The concise syntax of Scala makes it very easy to implement applications that are modeled leveraging DDD and the Scala bias to immutability makes the application cloud scale ready, even if you don't need that at first.

You can use Akka in Java as well.

Greg Young's CQRS documents use the word "segregation" but it also mentions that it "originated with Bertrand Meyer’s Command and Query *Separation* Principle" - neither of you are wrong of course :-)

I think there's many ways to do that, but you could add a "version" attribute to your events. The aggregates will need to be able to deserialise correctly all versions of an event, though.

for eventsourcing nice and sort example you can find github.com/RisingStack/event-sourcing-example it is in nodejs but the concept is really sort and simple

Hello Anug14, yes its good since we have several actors within the supply chain and the events happens in a sequential manner. You can think of reversals which entails transactions compensation

This is called snapshots. You would typically write code that dumps the in-memory model to persistent storage and read it back again when the system starts up. This is not necessarily faster than just replaying all the events, depending on the size and complexity of the projection and th number of events.

Loading millions or billions of events can take from a few minutes up to a couple of hours. If you have multiple replicas of each in-memory readmodel you can perform a rolling upgrade without downtime.

He explained it pretty straight and answer is you validate against read model which might not be up to date and you have inconsistent event store state now... and author says that it is not a big deal... it is a huge deal, I understand cool aspects of event sourcing but this fundamental eventual consistency is just a huge inconvenience. It is not only user registration there might be tens of examples where I want to validate current state of the system before commit next event and every time I should email a manager or make a discarding event?

@Stan Agreed and for the duplicate email address example used it would be very hard to explain to someone non-technical how it had occurred whilst maintaining a serious face. It also opens opportunities for malicious exploitation of inconsistent state. It does feel like going back to go forward.

CQRS as it stands today has very little value unless the business can live with its fundamental limitation of eventual consistency. Instead of accepting this limitation, proponents of CQRS turn the tables and say Strong consistency is bad. There is no sane way to get around eventual aspect. Commands are forced to go to event handler to get processed as and there is no sane way to achieve consistency without compromising latency How many businesses want their customer to signup again later because the event handler was busy handling other events. Sure, we can throw a lot of resources to achieve consistency, but is it really worth it? Sharding is a reasonable alternative if load on single strong consistent store does not scale well. May be distributed SQL stores like cockroach db might help if used smartly The only value you have is event sourcing which allows us to have business events & the ability to replay

Author's statement on this issue made me also uncomfortable because it is not such a process as simple as he defined when you look from the view of user perspective. I think (at least this is what I understood) what he wanted to mention was focus on your domain subject and if what you interested in that manner is out of the main domain then don't give too much care on it. In this particular case, if your main objective is not registering user (along the whole application) then skip this parts with simple actions???

Please mind that this talk has been given before GDPR ;-) I usually mention in my talks that data protection rules may force you to break that rule

One thing that was pointed out in another talk about CQRS and GDPR. When creating a new object have an event that generates an encryption key and add to the event queue. All user data can be encrypted using the encryption key and events are saved that way. The only thing that has to be modified if the user asks to be removed is to remove the save of the encryption key event. Now the data is encrypted and cannot be recovered but the events are not changed. This adds some overhead but if you are judicious with using data objects to save the personal data so encryption can happen on a block of data instead of fields at a time.

If you need a special logic for when the customer failed the verification, you would have to create an event "CustomerFailedVerificationEvent", basically you create the events you need for the business logic but the events must always indicate what happened.