aliostad's comments

Well, first of all, debugging while developing an actor is actually easier: you just have to debug an actor in isolation and make sure it does the right thing and sends the right event in response to the incoming event.

In terms of debugging issues when in live, you have to rely on tracing and let something such as Logstash handle search, etc.

The ordering of the workflow is preserved. As I explained, FraudCheck is only ever done after an order's payment has been authorised.

Hope this makes sense.

No it is not the same. First of all, CQRS is applying CQS to the architecture, so it is an architectural decision. When you use commands, you know about the interface of the endpoint receiving your message. In case of an event, you do not have to know anything - and this is the whole premise of this post. In the article to come, I have explained the differences more with regard to EIP as well. A half-draft available at https://gist.github.com/aliostad/55b652e44dfe87d44444

Yes, so many buzzwords together - I admit.

The difference is replacing Commnad/Query with events. Replacing Imperative with Reactive.

Did you read the whole post or you were put off by the buzzwords?

It is about High Availability. Have you ever tried to use a central broker in NSB? The best HA you get is clustering 2 machines. And that is not HA.

Author here. Point is middlewares that are not built from ground up to scale horizontally are bound to die. BizTalk uses SQL Server for its storage as such cannot be horizontally scaled. End of story. NServiceBus... well, let's not go there :)

+10.

>> You simply CANNOT explain to a .net zealot what big data is. They just don't get it

Could have not said it better.

I am mainly talking about server technologies. So yes, client technologies do not need to scale. But if the when even LOB apps need to work wit

Remember "Can't hurt", not quite true. I am shifting focus, so I am spending time that could be spending on learning and mastering, blogging, speaking Microsoft technologies. If I am wrong, it will hurt me.

This is a REST viewpoint so assumes all services are exposed by a REST API. ESB sits in the infrastructure layer and not the presentation - so these cannot be the same.

But I think you are right that in some enterprises ESB connects everything but in this case this is a really nice presentation to watch - back from 2008 http://www.infoq.com/presentations/webber-guerilla-soa

I am really happy if you think all of this is common sense. In fact a lot of software best practices are common sense but they do not necessarily consistent with each other. Even in life, "Always help others" and "Set your goals and run for them" are common sense but they will make a different person out of you. There comes a time when you are at a fork and need to make a decision and then it is down to which one is really what you believe in.

Decision to separate domains of client and server is a big one and has its implications. CSDS is common sense as is HATEOAS but they are not consistent. ROCA is also common sense but does not agree with CSDS.

Server cannot rely on client for storing its own domain's state - while client can store user-related state for improving performance, usability.

For example, twitter cannot rely on a client to store the tweets while the client could cache the recent tweets for improving user experience.

Again, for an app playing music, keeping bookmark of the last song played can be fully stored on the client. Yet if it is needed to sync this bookmark across multiple devices (similar to kindle) it becomes a server concern.

I will pay you 100$ if you could show me a single case of scamming from Iran. Honest.

I am saying they cannot access internet now you say they are using internet to scam? With money transfers impossible due to financial sanctions, it is impossible to do any scamming from Iran.

The reason mentioned by PayPal was the financial restrictions due to sanctions.

I wanted to do this but felt it is cheating on xkcd. He did not intend this to viewed as such.