The distinction between value types and entities in functional programmingĬlassical (read object oriented) implementation of DDD differentiates between value types and entity types, based on their mutability and notion of identity. Identifying verbs was also an important part because it decides which operation should be in the domain. Nouns correspond to data structure and verbs correspond to operation in your domain.
Ubiquitous language is not only the collection of nouns in any domain but also the verbs, processes and constraints. However, in FP you tend to keep your data and functions separate. One misconception that I had while mapping concepts like aggregate in functional programming (FP) from object-oriented (OO) was to only think in terms of only because data and behavior always co-exist in OO. When one part of the aggregate is updated, other parts might also need to be updated to ensure consistency. An aggregate is a place where invariants are enforced and act as a consistency boundary. The idea behind aggregate is to enforce consistency and invariants. In this post, we will explore what makes domain-driven design a good fit even for functional languages.
Who is responsible for keeping the state internally consistent?ĭomain-driven design provides a set of patterns that address many issues like this. In a way, the problem is not the mutability of the state, it is the ownership of it. Sure, a copy is passed from one function to the next, but there is still one 'current' state and everything is messing with it directly. While making the state immutable made what code was affecting the state more visible, the end result is still multiple pieces of code directly affecting what is essentially a global state (perhaps, stored in a database). For example, it is often argued that a lot of ideas from domain-driven design can be discarded because functional languages use immutable data structures by default. Even if you manage to find one, it often lacks the true essence of functional programming.Īs a result, DDD is often considered as something only meant for object-oriented programming. Unfortunately, there are very limited resources when it comes to implementing DDD in functional languages. Domain-driven design (DDD) provides many techniques and patterns to tame complexities in software applications – even when those are written in functional languages.
0 kommentar(er)
