Domain Driven Design: The Good Parts - Jimmy Bogard

The greenfield project started out so promising. Instead of devolving into big ball of mud, the team decided to apply domain-driven design principles. Ubiquitous language, proper boundaries, encapsulation, it all made sense.
But along the way, something went completely and utterly wrong. It started with arguments on the proper way of implementing aggregates and entities. Arguments began over project and folder structure. Someone read a blog post that repositories are evil, and ORMs the devil incarnate. Another read that relational databases are last century, we need to store everything as a stream of events. Then came the actor model and frameworks that sounded like someone clearing their throat. Instead of a nice, clean architecture, the team chased the next new approach without ever actually shipping anything.

Beyond the endless technical arguments it causes, domain-driven design can actually produce great software. We have to look past the hype into the true value of DDD, what it can bring to our organizations and how it can enable us to build quality systems. With the advent of microservices, DDD is more important than ever - but only if we can get to the good parts.

NDC Conferences

[slopapa]

Great to hear specifics about actual application of DDD to real life projects. I appreciate his honesty and humility about their initial experience; such maturity is really needed as we discuss implementations of all these newer patterns and practices.

Thanks!

[finnurhrafn]

We should all thank the State of Texas for allowing Bogard to speak so openly about the development of these projects. The developer community as a whole benefits. Bogard as always a brilliant presenter.

[samb]

I'm amazed by Jimmy's honesty and openness both about the technical aspect of the project as well as about the legal system and how it works! great talk, thanks!

[jimifriis]

Thanks Jimmy!
Mostly for being humble and admitting mistakes - really valuable for the public (and me) - and for sharing the insights in the more successful project.
I have seen a project where many new techniques such as DDD, Event Sourcing, CQRS etc. was used at the same time and not fully understood by the team, and I presume there are many of those out there - of those that survived and made it to production :).

and thanks to NDC for uploading!

[mattbann]

"if lastName === 'Bogard' just go ahead and drop the case." brilliant.

[bdaniel]

I hope nobody from the judicial system in Texas saw this presentation. We'd miss you, JB ;)

[danielkrajnik]

I'm glad that he takes it so casually

[MrKibitz]

Really the illustration of this:
"If you look at software today, through the lens of the history of engineering, it’s certainly engineering of a sort—but it’s the kind of engineering that people without the concept of the arch did. Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. There’s this very long lag between what you might call the best practice in computing research over the years and what is able to leak out and be adapted in the much more expedient and deadline-conscious outside world."

[amluzia]

Really great case study - In UK, TOGAF enterprise architecture is common, its interesting to consider how this fits with domain driver design. In TOGAF 'views' and 'viewpoints' are the perspectives (reality slices) of the differering stakeholders

[vekzdran]

Jimmy dissing the blue book just at the end :p ... fantastic presentation and... explaining the whole workshop approach in discovering and figuring out knowledge. I am interested in how many diagrams and which kinds they had to use to map this out. I like the fact he points out so much the ubi lang and contexts, not the coding aspect of the whole problematic. And also... 0 value objects haha, I love that as it proves you do not need to be evangelistic at DDD but you can still make stuff work great. Amazing presentation Jimmy, thank you.

[lerpmmo]

i think at the end of the day there are 2 sides - you try and encapsulate and abstractify each entities ever evolving workflow, OR you create a powerful tool that molds into different use cases and the agency/companies adapts to it. the computer itself is not engineered specifically for any business, its just made in a way where it can be flexible enough to be molded into different scenarios. so the solution is something in between those 2 paths, you want it abstract enough to have large spread but also optimized for the specific sector/industry.

[rudde]

An American speaker at the Norwegian Developer Conformance, in Sydney, Australia. Beautiful.

[shenth]

Good to learn about the taxas juvenile justice system

[soapissue]

This is where rubber meets the road. Just too good of an use case.

[wladif]

I would REALLY love to see a discussion of a system like this one, but using traits/mixins for implementing it.

[Vlfkfnejisjejrjtjrie]

37:26 "Boss Hog sheriff or something". 🤣🤣 Maybe there was at least one other American in the room who grew up in the 80's and remembers Dukes of Hazzard.

[schmal]

17:50 just remember, everyone: the first step to good software is contempt for your end users

[aflj]

I suspect your difficulty of using the tactical patterns comes from not having routine with them. They don't, in fact, require to be used. They provide a taxonomy of what you'll inherently create as you proceed with implementation. They are helpful with not mixing stuff. You know you need a struct. (It will be a full class in Java without JEP 169, but that doesn't make any difference.) You need to identify whether that struct is an entity or a value object, in order to know how you'll handle instantiation and mutation. Putting a label on the type when you create it helps with this. But even without the label, you should still take care of such aspects.

[chrise]

Had to use a speaker amplifier. Wondering if NDC is taking donations for the "microphones procurement" fund.

[califrexan]

I'm trying to understand the need for having a monolithic Repository w/ 90 methods in the first system. Why not break it down into many more Repos?