The problem is that a “business domain” which is not allowed to have invalid state at any time is not a real thing that exists in the real world.
Having modelled numerous business domains now, and implemented them, this is absolutely false. It seems to me that you’re blurring lines. The business domain is actually something you -can- control and manage, establishing clear boundaries and ensuring that valid state is the only way in which a bounded context can operate safely. You’re blurring the lines with your point about Enterprise software, and I see such arguments made a lot, that because X is done badly, X must be bad. This is a false dichotomy. And to be honest I don’t really know what you mean by “Enterprise software”. It’s a rather loaded term that means different things to different people.
You imagine a situation in which the state is allowed to be invalid for a little while, as a treat, but once it reaches the backend it must necessarily be beaten into shape by validators and never allowed to deviate again.
Not once it reaches the backend, once it reaches a domain boundary. It’s a subtle but technically important piece.
Also, replying to a separate comment you made to someone else: for context, I have implemented undo/redo and guess what - that was in a DDD application and it was technically gorgeous, with enforced valid state at all times. At the time we could not believe how easily event sourcing (in particular) handled this component, literally out of the box.
Coming back to the topic at hand, let’s think about something like an email address. If you want to work with valid email addresses in your domain, how do you enforce that? Just assume that the string that is provided is always a valid email and push any errors further down your stack, maybe minutes or months after the invalid email was created?
I realise you’re not saying “never enforce valid state”, but it also seems a stretch to extrapolate that out to “valid state is never possible”. My experience (of which I have over 25 years, as a software engineer and CTO), has demonstrated otherwise. In fact, I would go so far as to say that the best applications I have built, have been in the last 5-10 years as I’ve learnt about DDD and the power it brings to software development.
