Model pollution always happens - when I started it was Enterprise JavaBeans bits, and these days it's just as likely to be Spring Framework stuff. Add yourself some sub-packages if you like to keep things tidy.ĭo please note: it’s natural to get a little frustrated as framework and plumbing stuff - stuff that really isn’t a model - starts to creep into this "model" package. I like to make a package called "model" but others call it "domain".
Why? Because your code is just a much more tightly constrained, compiler-checked, version of the models you draw with a pen, and as such, as you write your code you’re still making many design decisions.Īs you go, treat yourself to a separate place in your codebase to keep things which are model-y. Remember - people who write the code should draw sketch diagrams, but those who draw sketch diagrams must write code. Stage 2: Don’t just draw, coding is modelling too As you do this, remember to keep moving to the code - keep the loop between a sketch on a whiteboard and the corresponding code super tight.
And the old but still great " UML Distilled" by Martin Fowler is also very handy. Take a look at Simon Brown's stuff for easy ways into this if you need it. Don't worry, you don't need to be a UML-master. Ideally, you'll have a whiteboard, but online tools like draw.io are great too. Now, let's try and understand our business problem.Īs you do this it's nice to be thinking using the same concepts you'll use to write code - that is to say, if you're going to write code in an Object-Oriented language, model in an OO way too. Forget ‘bounded contexts’, ‘ubiquitous language’, and all that other stuff - even forget the word ‘domain’. Simply try and understand what problem you're solving with your software.
Remember the days before you had ever heard about domain-driven design and you'd just model your software domain using boxes and lines? Stage 1: Start with the business problem So how do you begin? Forget about DDD. That makes me sad, because DDD is the thing which keeps me sane on projects, keeps codebases in line and close to the business problem, and most importantly helps teams organise and deliver.
Yet despite all these, folks are still getting put off by the sheer volume of info, and perhaps even the number of options for how to start. You could try Vaughn’s " Domain-Driven Design Distilled", or perhaps, my personal favorite, " The Anatomy of Domain-Driven Design" by Scott Millet and Sam Knight. “ Implementing Domain-Driven Design” by Vaughn Vernon is the most well known - but it’s even longer. In it he defined DDD as “an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts.” This book, while incredibly readable (one of my top three books for developers) can also be off-putting: at 560-pages, it’s a weighty tome.Įvans’ book isn’t the only one on DDD. What is “domain-driven design”? When I say ‘domain-driven design’ I'm talking about the design process introduced by Eric Evans in his 2003 book " Domain-Driven Design: Tackling Complexity in the Heart of Software". You’ll also get a framework to build upon as you move towards mastery of DDD, which is one of the few proven ways to "tackle complexity at the heart of software". There’s some practical advice, and a few suggestions about significant milestones in your learning journey. It will flag things about DDD that are worth thinking about, as well as things you can safely ignore. This blog post explores the fundamentals of DDD and gives you a path to follow. Frequently problems start in the very early stages. DDD is hard I've seen many teams adopting domain-driven design (DDD), and I've seen things go wrong a lot.