[–] Quokka-labs 28d ago ↗ The biggest shift is treating tests and constraints as the source of truth, not the generated code. [–] m110 28d ago ↗ Isn't code what defines the constraints though? [–] rrook 28d ago ↗ The domain and delivery/ops context define the constraints, code that gets written ought reflect those constraints, not provide more.
[–] m110 28d ago ↗ Isn't code what defines the constraints though? [–] rrook 28d ago ↗ The domain and delivery/ops context define the constraints, code that gets written ought reflect those constraints, not provide more.
[–] rrook 28d ago ↗ The domain and delivery/ops context define the constraints, code that gets written ought reflect those constraints, not provide more.
[–] rrook 28d ago ↗ Sure, the domain model isn't an artifact, but software _necessarily_ contains an artifact of the domain model. [–] m110 28d ago ↗ Makes sense, but this artifact is still a simplification, right? The domain model isn't just this one artifact in the code but the broader "idea". [–] rrook 26d ago ↗ Absolutely - it's like, the "current agreed upon version", but indeed it's a point-in-time snapshot/simplification of whatever the thing being modeled actually is.
[–] m110 28d ago ↗ Makes sense, but this artifact is still a simplification, right? The domain model isn't just this one artifact in the code but the broader "idea". [–] rrook 26d ago ↗ Absolutely - it's like, the "current agreed upon version", but indeed it's a point-in-time snapshot/simplification of whatever the thing being modeled actually is.
[–] rrook 26d ago ↗ Absolutely - it's like, the "current agreed upon version", but indeed it's a point-in-time snapshot/simplification of whatever the thing being modeled actually is.
6 comments
[ 3.7 ms ] story [ 23.1 ms ] thread