João P. BragançaRecently a question came up in the CQRS chatroom on Jabbr: Here’s the situation. New command comes in, They can sometimes be missing some info (for daft reasons), if it is missing info then I need to call off to an external api to get the info back. This external api is unreliable so it would be better to supply the information upfront if possible.
There are a couple of ways to do this.
João P. BragançaThe fastest information can ever travel is 3*10^8 m/s - in a vacuum. It’s 2/3rds that in a copper wire. In the ideal case.
Imagine two observers in the milky way galaxy, one at Terminus and the other at Star’s End. They will observe events from all over the universe at different times - they will not agree on the order of events. What they can agree on is that eventually they will see all of them.
João P. BragançaA discussion came up recently on the DDD/CQRS forums recently, that got sidetracked into ‘where do the validations go’ (along with a lot of weird nonsense about async command queues, http status code pedantry, etc, but we’ll leave that for some other time). A large minority of developers - perhaps even a majority - seem to think that validations belong somewhere in the ‘trusted’ client.
I find this conclusion strange, as none of the .
João P. BragançaThe Soap Box Part We’ve heard this before, but it bears repeating: CQRS is not just for greenfield event-sourced ddd systems. It can apply to crappy brownfield systems too. It may even have more relevance there.
Let’s take the penultimate brownfield system, an ERP system. In particular, Navision. Navision has a fantastic interface for interacting with it (snipped for brevity):
public interface SalesPrice_Port { Read_Result Read(Read request); ReadMultiple_Result ReadMultiple(ReadMultiple request); Create_Result Create(Create request); Update_Result Update(Update request); Delete_Result Delete(Delete request); } In other words, a 100% behavior free SQL-like interface that isn’t sql because you have Create / Read instead of INSERT / SELECT.