3 ms·

Hah! Try to separate your domain logic from your interfaces (e.g., using something like hexagonal architecture) and then say this again. Yes, it's a lot of wor

Hah! Try to separate your domain logic from your interfaces (e.g., using something like hexagonal architecture) and then say this again. Yes, it's a lot of work coming up with good properties, but it massively helps to find gaps in the domain logic. In my experience, these gaps are what's typically expensive, not the weird problem a junior had with properly using Redis or S3.

hitchstory 2y ago
>Hah! Try to separate your domain logic from your interfaces Im not an amateur. The only time I dont do this is when there literally is no domain logic yet (e.g. a CRUD app). >In my experience, these gaps are what's typically expensive, not the weird problem a junior had with properly using Redis or S3. What can I say? Your experience might not be as broad as mine. Redis is a source of almost no bugs because it is very well designed, but most interfaces I couple to have design qualities that are the exact opposite of redis's. Those interfaces (e.g. wonky payment gateway APIs, weird microservice APIs) are the probably source of most bugs in enterprise systems I work on. #2 is probably simple misspecifications (customer said code should do X, it should actually do Y which is almost the same but very slightly different). #3 would be domain logic errors. And even most of those are uncovered and avoided with saner architecture or a couple of unit tests. For the parsers I write at home, sure, property testing kicks ass. For your college degree algorithm coursework, sure, it helps a lot. For 95% of business logic? Pointless, the complexity isnt buried deep in the business logic.