DEV Community 👩‍💻👨‍💻

Discussion on: Understanding Domain Driven Design with some Pizza

Collapse
 
tomasforsman profile image
Tomas Forsman

A problem occurs when customers keep telling the delivery guy that the pizzas have way to little cheese and the delivery guy don't let the chefs know.

Narrow focus is not always the best approach; at least not in a real world context. In the technical domain you can separate the "delivery guy model" into navigation, transport and customer interaction systems. The customer interaction system feeds data into the feedback store. The recepie builder system uses data from the feedback store to make adjustments to pizza recepies and continously update the recepie data store. The chef system in turn keeps using the recepie store when making pizza.

The recepie bilder also uses other data stores with data coming from the economy systems to make sure the recepies are profitable.

The real world is way to complex to be separated into clean concerns and need more open paths of communication. In a micro service architecture we can model this by using data stores that emulates shared knowledge. In real world we can't rely on the same clean collection and separation of data.

As an introduction it is a nice koncept with a restaurant as a domain since it is full of roles with somewhat narrow concerns. It is important to note though that it is not a 1:1 conversion and explain how real world communication translates into decoupled systems and data.