- Can I DDD?
- Why You Should Do DDD
- How To Do DDD
- The Business Value of Using DDD
- The Challenges of Applying DDD
- Fiction, with Bucketfuls of Reality
- Wrap Up
From the Rough Cut
From the Rough Cut
From the Rough Cut
Fiction, with Bucketfuls of Reality
As I contemplated how to best present implementation guidance for contemporary use of DDD, I wanted to provide justification for everything I say should be done. That meant supplying not just the how, but the why. It occurred to me that looking at a few projects as case studies would appropriately illustrate why I made a certain suggestion, and demonstrate how proper use of DDD will solve the challenges commonly faced.
Sometimes it's easier to look at the problems faced by other project teams and learn from their misuse of DDD than it is to look inward. Certainly, once you recognize the flaws of others' work you'll be able to judge whether or not you are leaning in the same precarious direction, or even standing in the thick of the same morass. Then, knowing where you are headed or where you already are, you can make the precise adjustments to correct problems and avoid the same in the future.
Rather than present a series of actual projects that I have worked on—ones that I could not discuss openly—I decided to use a bit of fiction based on real-world situations that I and others have experienced. That way I could create the perfect state of affairs to demonstrate the reasons a specific implementation approach works best, or at least better, when dealing with challenges in DDD.
So it is not just fiction on which I am interested in building case studies. It is a fictitious company with a real-world business charter, fictitious teams within the company with real-world software to build and deploy, and real-world DDD challenges and resulting problems with real-world solutions to them. It's what I call “fiction with bucketfuls of reality.” I have found it quite effective to write in this style. I hope you benefit from it.
When presenting any set of examples, we must limit the scope to make it practical. Otherwise, the volume will drown efforts to teach and learn. Examples cannot be overly simplistic either, or vital lessons would be lost. To balance this effort, the business situation I have chosen is largely based on greenfield development.
As we peer into the projects at various points in time, we'll see different problems and successes that the teams experience. The Core Domain that is the focus of the examples is sufficiently complex to examine DDD from various perspectives. Our Bounded Contexts use one or more others, which enables us to investigate integration with DDD. Still, the three sample models cannot possibly demonstrate every aspect of strategic design, such as occurs in a “brownfield” environment common where many legacy systems exist. I don't completely dodge those less attractive regions, as if they are irrelevant. Whenever advisable we will diverge from the main samples and study areas where DDD guidance can be used in additional advantageous ways.
Now allow me to introduce you to the company and tell you a little bit about their teams and the projects they are working on.
- SaaSOvation, Its Products, and Its Use of DDD
The company is SaaSOvation. As its name implies, SaaSOvation's charter is to develop a series of Software as a Service, or SaaS, products. The SaaS products are hosted by SaaSOvation and accessed and used by subscribing organizations. Its business plan includes two planned products, one to precede the other.
The flagship product is named CollabOvation. It is a corporate collaboration suite, which sports the features of leading social networks. These include forums, shared calendars, blogs, instant messaging, wiki, message boards, document management, announcements and alerts, activity tracking, and RSS feeds. All of the collaboration tools are focused on the needs of corporate businesses, helping them spike productivity in smaller projects, larger programs, and across business units. Business collaboration is important for creating and facilitating a synergistic atmosphere in today's changing and sometimes uncertain, yet fast-paced economy. Anything that can help propel productivity forward and transfer knowledge, promote idea sharing, associatively manage the creative process so results will not be misplaced, is going to be a boon to the corporate success equation. CollabOvation provides a high value proposition to customers, and the challenge will also please its developers.
The second product is named ProjectOvation, and is the Core Domain of primary focus. The tool focuses on the management of agile projects, using Scrum as the iterative and incremental project management framework. ProjectOvation follows the traditional Scrum project management model, complete with product, product owner, team, backlog items, planned releases, and sprints. Backlog item estimation is provided through business value calculators that use cost-benefit analysis. If you think Scrum at its richest, that's where ProjectOvation is headed. But SaaSOvation plans to get more bang for its buck.
CollabOvation and ProjectOvation would not go down entirely separate paths. SaaSOvation and its board of advisors envisioned innovation around weaving collaboration tools in with agile software development. Thus, CollabOvation features will be offered as an optional add-on to ProjectOvation. Without a doubt, supplying collaboration tools for project planning, feature and story discussions, team and inter-team group discussion and support, will be a popular option. SaaSOvation forecasts that more than 60% of ProjectOvation subscribers will add on CollabOvation features. And this kind of add-on sales often ends up leading to new full sales of the add-on product itself. Once a sales channel is established and software development teams see the power of collaboration in their project management suite, their enthusiasm will influence full corporate adoption of the complete collaboration suite. Due to this viral sales approach, SaaSOvation further forecasts that at a minimum 35% of all ProjectOvation sales will lead to full corporate adoption of CollabOvation. They consider this a conservative estimation, but one that will make it extremely successful.
The CollabOvation product development team is staffed first. There are a few seasoned veterans on the team, but a greater number of mid-level developers. Early meetings pointed to domain-driven design as the favored design and development approach. One of the two senior developers had used a minimal set of DDD patterns on the previous project at his former employer. As he described his experience to the team, it would have been clear to a more experienced DDD practitioner that this was was not full use of DDD. What he had done is sometimes referred to as DDD-Lite.
DDD-Lite is a means of picking and choosing a subset of the DDD tactical patterns, but without giving full attention to discovering, capturing, and enhancing the Ubiquitous Language. As well, this technique generally bypasses the use of Bounded Contexts and Context Mapping. It's focus is much more technical, with a desire to solve technical problems. It can have benefits, but generally not with as high a reward as including strategic modeling along with it. SaaSOvation bought into this. In their case it soon led to problems because they didn't understand Subdomains and the power and safety of explicit Bounded Contexts.
Things could have been worse. SaaSOvation actually avoided some major pitfalls of using DDD-Lite, just because their two core products formed a natural set of Bounded Contexts. This tended to keep the CollabOvation model and the ProjectOvation model formally segregated. But that was just by chance. It didn't mean they understood Bounded Context, which is why the problems they did experience happened in the first place. Well, you either learn or you fail.
It's good that we can benefit from examining SaaSOvation's incomplete use of DDD. They eventually learned from their mistakes by acquiring a better grasp of strategic design. You will also learn from the adjustments the CollabOvation team made, as the eventual ProjectOvation team benefited from retrospectives of the early conditions of its sister and partner project. See Subdomains and Bounded Contexts, as well as Context Maps, for the full story.
