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:

Scott Wlaschin advocates for embedding business rules directly in th

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

Here are some practical exercises we could do:

Think about a real-world system you're familiar with (e.g., a shopping cart, a library management system, a flight booking system). For each one:

• List out the core entities in the domain.
• Identify the key business rules (invariants) that must always hold true.
• Ask yourself: How would you model these rules as types and functions?

In chapter 5, p.95, Scott writes:

"First, is Order an Entity or a Value Object? Obviously it’s an Entity—the details of the order may change over time, but it’s the same order.

What about an OrderLine, though? If we change the quantity of a particular order line, for example, is it still the same order line? In most designs, it would make sense to say yes, it is still the same order line, even though the quantity or price has changed over time. So OrderLine is an Entity too, with its own identifier.

But now here’s a question: if you change an order line, have you also changed the order that it belongs to?

In this case, it’s clear that the answer is yes: changing a line also changes the entire order. In fact, having immutable data structures makes this unavoidable. If I have an immutable Order containing immutable OrderLines, then just making a copy of one of the order lines does not also make a copy of the Order as well. In order to make a change to an OrderLine contained in an Order, I need to make the c

The responsibility for creating unique identifiers (keys) for entities in a domain-driven design (DDD) system depends on the context and requirements of the application. There are several common approaches to generating these identifiers, each suited to specific use cases. Let’s explore these approaches and who is responsible for generating the identifiers in each case.

In some domains, the identifier is inherent to the entity itself and comes from the real-world domain.

Examples:

• Serial numbers for banknotes: In the state mint context, the identifier (serial number) is usually assigned during the manufacturing process. The mint’s production system generates the serial number and ensures uniqueness.

To setup a custom DNS on your TIM ZTE H388X router:

• head to "Rete Locale" -> "LAN" -> Server DHCP
• execute this script in the browser dev tools console

document.querySelectorAll('#template_DHCPBasicCfg [style*="display: none;"]').forEach(el => {
    el.style.display = ''; // Removes inline display:none
});

• you should see