Recently 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.
The 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.
Word on the street is value objects have been getting the short stick in
DDD ORMS. That's too bad. Value objects should be first class citizens because like aggregates their role is to enforce invariants. e.g.
DateTime.Parse("NOPE") // <-- nope
Sage advice. I almost made a huge mistake this sprint, but thankfully caught it because I had one last conversation with the domain expert before I deployed anything.
Sometimes our model can't be as pure as the driven snow. Sometimes we have to use a really crappy external model because replacing it outright would be too expensive. Typically we deal with this in our tests with some kind of mocking framework.
Example,we have a use case for 'creating' an item in the ERP system. Of course in real life nothing ever gets 'created.' Instead our inventory items are 'created' upstream in the product development context. Once the product has reached a certain point of development, they are released to manufacturing. They must go into the ERP system which is where purchase orders originate.