4 ms·
They seem to shine, but it's a mirage. Once you start naming your types "RequestWithoutId" you have committed to using language alien to everyone but engineers
by hbrn 3y ago
They seem to shine, but it's a mirage.
Once you start naming your types "RequestWithoutId" you have committed to using language alien to everyone but engineers (might even be alien to engineers).
There are tremendous benefits in using "ubiquitous language" (in DDD terms), and type-obsession means you'll never get there. Business and engineering goals will never converge. Engineers will live in their own little world, procrastinating in their type puzzles and feeling productive doing so.
- jkaptur 3y agoClear naming is important, and types help with that. "RequestWithoutId" is clunky, but it is easy to explain to an (interested!) business-side person that you have "external requests" (from the outside world) that you validate and transform to "internal requests" (passed around your system). It's certainly easier than if you have no names or types at all!
- Terr_ 3y agoThat's not a problem with the approach, that's a problem with the specific naming. An original request without an ID still has some kind of business relationship, even if only because it really did exist at one point in the past. So there's _some_ proper name out there, even if it's something like InternalRequest or InformalRequest or ObsoleteRequest or BeforeTheMergerRequest.
- kuratkull 3y agoThose kinds of systems are a real joy if designed correctly. You can usually pretty safely assume that the object does not mutate (much), and you can very easily find out what you need to do to pass that object forward into a function that requires RequestWithId. Look up the concept of "make illegal states unrepresentable." EDIT: RequestWithoutId is not the best example of this, but the point remains