In this series, I explain how I apply Domain Driven Design (DDD) in Go projects. This is not meant to be a definitive guide on how this should be done. Instead, I want to show you how it can be done. These are the methods I have come to apply frequently, after trying out many different ways, and they work quite well for me. But I’m still fine-tuning these methods frequently. Hopefully you’ll be able to extract some inspiration and teachings from them.
Some of the methods I describe deviate from what is commonly regarded as the ‘proper’ way of implementing DDD. When this happens, I will always try to explain why. It’s my personal opinion that DDD should be treated as a toolbox from which to select a subset of tools to use. I feel being dogmatic is almost never a good idea. The ‘right’ way of doing things almost always depends on the context in which it’s applied. Instead, I advocate for extracting learnings from DDD’s teachings and applying those learnings in a way that best fits the situation.
These methods may be incomplete. I might have overlooked something. Or they may not work very well for your specific problem domain. When that’s the case, I’d love to learn from you! So please leave your comments or questions under the posts.
In an ideal world non-technical colleagues would be able to read our code and quickly recognise the concepts, rules and processes that make up the business. We might never reach such an ideal but I’d argue we should strive for it nonetheless. Value Objects offer one way of getting us closer to that ideal situation.
Where Value Objects represent pieces of immutable data without an identity, entities represent identifiable elements within our systems. Entities generally have a lifecycle. They can be created, oftentimes deleted and are expected to be mutated during their lifespan.