MMS • RSS
- Two separate projects within similar domains, both implemented using DDD, provided an interesting opportunity to learn from missteps and do better.
- Bounded contexts weren’t used on the first project because it would have required the client to buy into building smaller systems.
- The biggest difference between the two projects was embracing bounded contexts and creating anti-corruption layers.
- Ubiquitous language is limited to within a bounded context. While some terms can be used throughout a wide domain, the definitions can be vastly different.
At the 2017 Explore DDD conference, Jimmy Bogard spoke about a rare opportunity to have what he considered a “do-over” on a project. While not a complete, start-from-scratch rewrite, he worked on two very similar projects, for related companies. InfoQ met with Jimmy to discuss how the lessons learned from the first project were applied to make the second more successful.
InfoQ: “If we could do everything over again…” is a common refrain for anyone who has worked on a large software project. That wisdom of hindsight usually helps guide future projects. You had the rare opportunity to actually work on two projects, a few years apart, with almost the same client and domain. What can you tell us about the clients, the projects, and the major objectives?
Jimmy Bogard: The ultimate end users were Texas state employees, spanning many different geographic boundaries. The first system is a case management system for juveniles, covering every aspect of the legal process. The overall goal of the juvenile system isn’t to punish, but to provide help for kids that run afoul of the law. The clients included counties for the major metropolitan areas of the state, as well as a state agency charged with oversight of each county program.
The second system was a bit more constrained – providing a single system solely for county prosecution departments for the state of Texas, and only for the adult process.
InfoQ: When the first project was started in 2007, DDD was still a fairly new idea. What was the experience level among your team, and at the client, with DDD concepts, such as domain modeling, ubiquitous language, and bounded contexts?
Bogard: The tech lead (myself) and the architect had a few years of experience building systems DDD-style. My first DDD project was in 2005, where I also introduced XP and Scrum to a product team. We did not have as much experience with bounded contexts, though the community at the time was much more focused on the structural patterns.
InfoQ: Do you think that level of experience led to any major missteps along the way? For example, did the software have unnecessary complexity due to the design and development practices that were followed?
Bogard: No, not really. It took a few projects to iterate over design concepts that morphed into what we did today. The biggest mistake – no bounded contexts – would have required the clients to buy in to building smaller systems. That was not going to happen. Otherwise, we were very careful to build only what we needed and design to the assumptions that we knew. Because the scope was so large, we knew that we couldn’t gold plate if we had any hope of finishing, so we were diligent about pushing back on complex requirements.
InfoQ: The system was built and paid for by one agency, but had to meet the needs of various other groups. Did this lead to any compromises in the design of the domain model? Was the language used truly ubiquitous?
Bogard: Absolutely this led to compromises in the design. Sometimes our design was a bit naive, and once we learned the full domain in an area, we’d see its design would be fundamentally incompatible with the rest of the system. So, we had to compromise. Regarding language, we found that while the terms were ubiquitous, the meanings behind them could be different. This would only surface once we’d get various domain experts in the room, and we’d discover that coming in, everyone thought they agreed, but at the end of a meeting, no one did.
InfoQ: On your second project, what were some major differences about the approach, specifically from a DDD perspective? How were these differences reflected in real life situations?
Bogard: The biggest difference was embracing bounded contexts. We built anti-corruption layers between our system and others, so that when another agency interfaced with us, the terms and design were familiar to them but we’d translate internally. For example, both law enforcement and prosecutors have a concept of an “offense”. In our actual system, we partitioned the two concepts so that there were two “offense” domain objects – one for law enforcement, and one for us. Keeping them separate meant that we could grow each independently of the other.
InfoQ: Unlike your first project, which rigidly followed patterns, your second project took a far more pragmatic approach. What are some recommendations you have for getting a project completed, while still achieving high-quality, maintainable code that meets the customer’s needs?
Bogard: That projects are marathons, not sprints. Approach with more of a product thinking, instead of project, designing for the long term, but around only the verified assumptions we’ve made. If we make new discoveries, then we build plans to incorporate those changes instead of letting our design rot over time.
InfoQ: Do you have any recommendations for readers looking for more of the design advice that you followed?
Bogard: SOLID in Slices not Layers
About the Interviewee
Jimmy Bogard is chief architect at Headspring, author of the MVC in Action books, an international speaker and prolific OSS developer. He is an expert in distributed systems, REST, messaging, domain-driven design and CQRS.