You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Instantly share code, notes, and snippets.
💭
😏
Pietro Di Bello
xpepper
💭
😏
Hi! I'm Pietro 👋
Lead Software Engineer with a passion for problem solving, visualization, XP and refactoring. I thrive on continuous learning & collaboration
A devcontainer setup for practicing F# with code kata
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
A shell script to create a temporary disposable email via command line (install w3m, curl, jq)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Kill all Rancher Desktop leftover to be able to use again Warp client :D
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Talking about chapter 6, I want to add a question on the part where the author states "of course, we could add special runtime validation checks to make sure that this couldn’t happen."
The question is: Aren’t the check pushed to the edge of the system? Somewhere there will be logic for deciding if we want to create a EmailContactInfo, PostalContactInfo or BothContactMethods. Shouldn’t this logic be (unit) tested?
For sure the logic for deciding whether to create an EmailContactInfo, PostalContactInfo, or BothContactMethods does need to be implemented somewhere! In fact, this decision-making logic—let's call it the "creation logic"—becomes the entry point where the business rule is enforced. Here's how that ties into the points raised in the book and your question:
1. Pushing Validation to the Edges
Scott Wlaschin advocates for embedding business rules directly in th
Are we used to create too few types to model our domains?
One thing I’m getting by reading chapter 6 is that we typically create very few types for describing and modeling a business domain, while one of the key learnings I got from this chapter that we should aggressively create types to capture differences and nuances, and to properly describe the different states of business workflows.
(e.g. not an EmailAddress but a UnverifiedEmailAddress and a VerifiedEmailAddress)
Chapter 6 is all about using types as a way to explicitly model and describe the domain in a precise and meaningful way. This means creating types to capture subtle differences and distinctions in your domain that are often overlooked when using a less type-focused approach.
So, yes, we should aggressively create types when modeling a business domain. This isn’t about creating types for the sake of complexity but rather about creating types to represent the real-world states and constraints of your business workflows in a clear, unambiguous way. This helps make your code more expres