Getting Started with Domain-Driven Design
This excerpt is from the Rough Cuts version of the book and may not represent the final version of this material.
From the Rough Cut
From the Rough Cut
From the Rough Cut
“Design is not just what it looks like and feels like. Design is how it works.”
—Steve Jobs
We strive to produce quality in the software we develop. We achieve some quality by using tests to help us avoid delivering software with a fatal number of bugs. Yet, even if we could produce completely bug-free software, that in itself does not necessarily mean that a quality software model is designed. The software model—the way the software expresses the solution to the business goal being sought—could still suffer greatly. Delivering software with few defects is obviously good. Still we can reach higher for a well-designed software model that explicitly reflects the intended business objective, and our work may even reach the level of great.
The software development approach called Domain-Driven Design, or DDD, exists to help us more readily succeed at achieving high-quality software model designs. When implemented correctly, DDD helps us reach the point where our design is exactly how the software works. This book is about helping you correctly implement DDD.
You may be completely new to DDD, you may have tried it and struggled, or you may have already succeeded with it before. Regardless, you no doubt are reading because you want to improve your ability to implement DDD, and you can. The chapter road map helps you target your specific needs.
Road Map To This Chapter
- Discover what DDD can do for your projects and your teams as you grapple with complexity
- Find out how to score your project to see if it deserves the DDD investment
- Consider the common alternatives to DDD and why they often lead to problems
- Grasp the foundations of DDD as you learn how to take the first steps on your project
- Learn how to sell DDD to your management, domain experts, and technical team members
- Face the challenges of using DDD armed with knowledge of how to succeed
- Look in on a team that is learning how to implement DDD
What should you expect from DDD? Not a heavy, dense, ceremonial, process that blocks your way to progress. Rather, expect to use the agile development techniques you probably already have come to trust. Beyond agile, anticipate the acquisition of methods that help you gain deep insight into your business domain, with the prospect of producing testable, malleable, organized, carefully crafted, high-quality, software models.
DDD gives you both the strategic and tactical modeling tools necessary to design high-quality software that meets core business objectives.
Can I DDD?
You can implement DDD if you have:
- a passion for creating excellent software every day, and the tenacity to achieve that goal
- the eagerness to learn and improve, and the fortitude to admit you need to
- the aptitude to understand software patterns and how to properly apply them
- the skill and patience to explore design alternatives using proven agile methods
- the courage to challenge the status quo
- the desire and ability to give attention to details, to experiment and discover
- a drive to seek ways to code smarter and better
I'm not going to tell you that there isn't a learning curve. To put it bluntly, the learning curve can be steep. Yet, this book has been put together to help flatten the curve as much as possible. My goal is to help you and your team implement DDD with the greatest potential for success.
DDD isn't first and foremost about technology. At its most central principles, DDD is about discussion, listening, understanding, discovery, and business value, all in an effort to centralize knowledge. If you are capable of understanding the business in which your company works, you can at a minimum participate in software model discovery process to produce a Ubiquitous Language. Sure, you're going to have to learn more about the business, lots more. Still, you are on your way to succeeding with DDD already because you can comprehend the concepts of your business, you revel in developing great software, and that gives you the proper footing to take DDD all the way.
Won't having years, even a decade of two of software development experience, help? It might. Nevertheless, software development experience doesn't give you the ability to listen and learn from Domain Experts, the people who know the most about some high-priority area of the business. You are at a greater advantage if you can engage with those who seldom, if ever, express themselves using technical lingo. You're going to have to listen and listen carefully. You're going to have to respect their viewpoint and trust that they know a lot more than you do.
What you may like best about DDD is that the domain experts are also going to have to listen to you. You are on the team the same as they are. As strange as it may seem, the domain experts don't know everything about their business, and they are also going to learn more about it. Just as you are going to learn from them, there is a high probability that they are also going to learn from you. Your questions about what they know will most likely also uncover what they don't know. You'll be directly involved in helping everyone on the team discover a deeper understanding of the business, even shaping the business.
It's great when a team learns and grows together. If you give it a chance, DDD makes that possible.
So far we're off to a pretty reassuring start. Still, I am also not going to tell you that technical ability isn't important, that somehow you can get by without it. You will have to grasp some advanced software Domain Modeling concepts. Even so, it doesn't necessarily mean you are going to be in over your head. If you have abilities somewhere between grasping Head First Design Patterns [Freeman, et al.] and grokking the original Design Patterns [Gamma, et al.] text, or even more advanced patterns, you stand a really good chance of succeeding with DDD. You can bank on this: I'm going to do everything I can to make that happen by lowering the bar, no matter what your level of experience.
Consider the following perspectives of the people who can benefit from DDD. I know you fit in here somewhere:
- Newbie, junior developer: “I'm young, with fresh ideas, and I've got pent up energy to code and I'm going to have an impact. What's got me miffed is one of the projects I sprint on. I didn't expect that my first gig off campus would mean shoveling data back and forth using lots of almost identical, yet redundant “objects.” Why is this architecture so complex if that's all that's happening? What's up with that? The code breaks a lot when I try to change it. Does anyone actually understand what it's supposed to do? Now there are some complex new features I have to add. I regularly slap an adapter around legacy classes to shield me from the goo. No joy. I am sure there's something I can do besides code and debug all day and night just to finish iterations. Whatever that is, I'm going to track it down and own it. I heard some of the others talking about DDD. It sounds like Gang of Four, but tuned for the Domain Model. Nice.”
- Mid-level developer: “Over the past few months I've been included on the new system. It's my turn to make a difference. I get it, but what I'm missing are profound insights when I am meeting with the senior developers. Sometimes things seem whacked, but I am not sure why. I am going to help change the way things are done around here. I know that throwing technology at a problem only takes you so far, and that's basically not far enough. What I need is a sound software development technique that's going to help me become a wise and experienced software practitioner. One of the senior architects, the new guy, made a pitch for something called DDD. I'm listening.”
- Senior developer, architect: “I've used DDD on a few projects, but not since landing this new position. I like the power of the tactical patterns, but there's a lot more I could apply, with strategic design being one. What I found most insightful when reading [Evans] was the Ubiquitous Language. That's powerful stuff. I've had discussions with a number of my teammates and management, trying to influence DDD's adoption here. One of the new kids and a few of the mid-level and senior members are jazzed about the prospects. Management isn't so excited. I recently joined this company, and although I was brought in to lead, it seems that the organization is less interested in disruptive advancements than I thought. Whatever. I'm not giving up. With other developers psyched about it, I know we can make it happen. The payoffs are going to be much greater than anticipated. We'll draw the pure business people—the domain experts—closer to our technical teams and we'll actually invest in our solutions, not just grunt them out
Now that's what a leader does. This book has lots of guidance that shows how to succeed with strategic design.
- Domain expert: “I've been involved in specifying the IT solutions to our business challenges for a long time now. Maybe it's too much to expect, but I wish the developers understood better what we do here. They're always talking down to us like we're stupid. What they don't understand is, if it wasn't for us there wouldn't be jobs here for them to mess around with computers. The developers always have some strange way of talking about what our software does. If we talk about A, they say it's really called B. It's like we have to have some sort of dictionary and road map on hand every time we try to communicate what we need. If we don't let them have their way by calling B what we know is A, they don't cooperate. We waste so much time in this mode. Why can't the software just work the way the real experts think about the business?”
- Manager: “We are shipping software. It's not always with the greatest result, and changes seem to take longer than they should. The developers keep talking about some domain something-or-another. I am not sure we need to get high centered on yet another technique or methodology, like it's some kind of silver bullet. I've heard all that a thousand times before. We try, the fad dies, and we are right back to the same-old same-old. I keep saying that we need to stay the course and stop dreaming, but the team keeps hounding me. They've worked hard, so I owe them a listen. They are smart people and they all deserve a chance to improve things before they get torqued and move on. I could allow them some time to learn and adjust if I can get backing from upper management. I think I could get that approval if I can convince my boss of the team's claims of achieving critical software investment and a centralization of business knowledge. Truth is, it will make my job easier if I can do something to inspire trust and cooperation between my teams and business experts. Anyway, that's what I am hearing I can do.”
Gotcha covered.
You're sounding senior already. Read on. Your forward-thinking attitude will be rewarded.
You've got that right. One of the biggest problems is the false need for translation between business people and techies. This chapter is for you. As you're going to see, DDD puts you and developers on level ground. And, surprise! You've got some developers already leaning your way. Help them here.
Good manager!
Whoever you are, here's an important heads up. To succeed with DDD you are going to have to learn something, and actually a lot of somethings. That shouldn't be a big deal, though. You are smart and you have to learn all the time. Yet, we all face this challenge:
“Personally I'm always ready to learn, although I do not always like being taught.”
—Sir Winston Churchill
That's where this book comes in. I've tried to make the teaching as pleasant as possible while delivering the vital understanding you need to implement DDD with success.
Your question, though is: “Why should I do DDD?” That's fair.