Re:Why Domain Driven Design?
by hcarvalhoalves on Friday November 25, 2022 @06:33AM
(#33741416)
Microservices alone don’t solve the shared mutable state problem, and make it even worse w/ network and eventual consistency.
[ Parent
| on HN ]
Re:Why Domain Driven Design?
by BulgarianIdiot on Friday November 25, 2022 @06:55AM
(#33741549)
They solve the mutable shared state problem that I'm specifically talking about. Which is that it's clear which state you own, and which state you don't own.
"Shared" implies shared ownership, this is where the confusion comes from. When you ask an API about a user's profile, it's that API's user profile. But the API response itself is entirely yours. It won't change right under your fingertips. The original profile may change, but you know that the profile is not yours already.
You don't need an HTTP boundary to make your own copy of data.
Re:Why Domain Driven Design?
by BulgarianIdiot on Friday November 25, 2022 @09:21PM
(#33749224)
Do you religiously deep-clone every container you pass to a function? No. So it's one thing to say you can copy your data, another to know your data is guaranteed to be copied.
Swift has value types which use pass-by-value semantics. Containers use copy-on-write. This is a language where you can quickly build value trees that you know are a guaranteed copy, isolated from whoever sent you this tree.
But most languages have no such infrastructure. Java is adding record types, but they're immutable instead of in-place mutable, which is incredibly inconvenient to work with in nested data structures.