Notes on the book Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#.
Understanding the domain
A developer’s job is to solve a problem through software.
define a shared model
- focus on business events and workflows rather than data structures
- partition the problem domain into smaller subdomains
- create a model of each subdomain in the solution
- develop a common language (known as the “Ubiquitous language”) that is shared between everyone involved
Business events
The value of the business is created in the process of transforming data.
Bounded Contexts
We therefore need to create a distinction between a “problem space” and a “solution space,” and they must be treated as two different things. To build the solution we will create a model of the problem domain, extracting only the aspects of the domain that are relevant and then re-creating them in our solution space
bounded contexts as autonomous software components
In general, an event used for communication between contexts will not be just a simple signal but will also contain all the data that the downstream components need to process the event.
trust boundaries and validation
The perimeter of a bounded context acts as a “trust boundary.” Anything inside the bounded context will be trusted and valid, while anything outside the bounded context will be untrusted and might be invalid.
The job of the output gate is different. Its job is to ensure that private information doesn’t leak out of the bounded context, both to avoid accidental coupling between contexts and for security reasons.
Contracts between bounded contexts
- A Shared Kernel relationship is where two contexts share some common domain design, so the teams involved must collaborate.
- A Customer/Supplier or Consumer Driven Contract relationship is where the downstream context defines the contract that they want the upstream context to provide.
- A Conformist relationship is the opposite of consumer-driven. The downstream context accepts the contract provided by the upstream context and adapts its own domain model to match.
- Anti-Corruption Layer in DDD terminology, often abbreviated as “ACL.” In the diagram above, the “input gate” often plays the role of the ACL—it prevents the internal, pure domain model from being “corrupted” by knowledge of the outside world.
build a context map with relationships
workflow within a bounded context
The input to a workflow is always the data associated with a command, and the output is always a set of events to communicate to other contexts.
avoid domain events within a bounded context
code structure within a bounded context
use onion architecture ~= clean architecture
keep IO at the edges
Understanding Types
represent a domain with ADTs
- AND types = product types = records
- OR types = SUM types = enums
Domain modeling with types
Use type systems to capture the domain model accurately and can be read and understood by domain experts.
simple types + sum/product types + functions
functions = workflows
Integrity and Consistency in the Domain
parse, don’t validate https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/
lots of examples…
Capturing Business Rules in the Type System
ex.
type CustomerEmail = | Unverified of EmailAddress | Verified of VerifiedEmailAddress // different from normal EmailAddress
type SendPasswordResetEmail = VerifiedEmailAddress -> ...
Making Illegal States Unrepresentable in Our Domain
Consistency
consistency = atomicity of persistence
Consistency between different context is hard, use eventual consistency:
- do nothing
- retry
- compensating action
only update one aggregation per transaction
Modeling Workflow as Pipelines
We’ll create a “pipeline” to represent the business process, which in turn will be built from a series of smaller “pipes.” Each smaller pipe will do one transformation, and then we’ll glue the smaller pipes together to make a bigger pipeline. This style of programming is sometimes called “transformation-oriented programming.”
Following functional programming principles, we’ll ensure each step in the pipeline is designed to be stateless and without side effects, which means each step can be tested and understood independently. Once we have designed the pieces of the pipeline, we’ll just need to implement and assemble them.
- Command as input
- Sharing Common Structures Using Generics
- Combining Multiple Commands in One Type
- Modeling an Order as a Set of States https://blog.yoshuawuyts.com/state-machines/
- Adding New State Types as Requirements Change
- Modeling Each Step in the Workflow with Types
- Creating the Events to Return
- Documenting Effects with signature
- Composing the workflow from the steps
Long-running workflow: Sagas
Implement the model
Understand functions
basic functional programming tutorial
Implementation: Composing a Pipelien
- Some functions have extra parameters that aren’t part of the data pipeline but are needed for the implementation—we called these “dependencies”
- We explicitly indicated “effects” such as error handling by using a wrapper type like Result in the function signatures. But that means that functions with effects in their output cannot be directly connected to functions that just have unwrapped plain data as their input.
Implementation: Working with Errors
Using the result type to make errors explicit. bind and map.
Serialization
persistence: state that outlives the process that created it Serialization: the process of converting from a domain-specific representation to a representation that can be persisted easily.
Persistence
- Push persistence to the edge
- CQRS
- Bounded Contexts must own their data storage