Domain-Driven Refactoring - Jimmy Bogard - NDC London 2022

Books, workshops, storming and more, all build up an idealized domain model. All describe great techniques for domain-driven greenfield applications. But what about the code we have? How can we take what's already built, and move it towards a better, more cohesive design?

In this session, we'll look at anemic, procedural, boring code and examine code smells that can point us in the right direction. We'll also look at standard design patterns for more complex behaviors and models, and how to recognize when (and when not) to apply them. Finally, we'll cover how to safely apply refactoring techniques to achieve our domain-driven model nirvana.

Check out more of our featured speakers and talks at

[kevinlloyd]

Love this talk. I rewatch it at least once a year!

[rshav]

This was so good that it made me want to go back to work :D

[Erril_Ferndal]

Amazing talk!! Every Developer should see this!

[NotARealPerson]

I think the Calculator can be moved to application layer. In my mind, a clean domain model interface should not have dependencies outside domain model. The domain model could require a calculated offer value to be passed to it, which can be provided by higher level logic. You could argue that both application layer and domain layer are just DOMAIN layer though. In the end, the whole DDD (not in microservice world, just talking about a single project here) is just about proper OO programming, which should be the way to go in the first place.

[marna_li]

This is such a great talk in all its iterations!

A couple of months ago, I was working on a project in which I wanted to put some domain logic with its Domain Object. In my scenario it was about a "Document" being signed. So I come up with creating a SigningService and pass in into the Document.Sign(signingService, signer). At first I felt uncomfortable, but the more I looked at it the more it made sense in OOP. Semantically: the Document is being signed by a Signer using a specified SigningService.

[wokker]

Learned some new Rider/Resharper tricks :)

[vin]

This is awesome. The way he explains is so clear. I think we can design our domain classes in our own way as long as its properly encapsulated and follows the single responsibility principle in SOLID.

[montassarkefi]

Thank you for your explanation, great to hear

[mahdimollaeian]

where can i download project source code?

[iorch]

For the average developer DDD is just a glorified set of basic OOP principles that got lost along the way because of the service layer pattern getting wild in the 00's.

The other part, contex mapping, bounded contexts, etc is mostly work for very expensive western consultants that rarely gets into production systems. There is a huge industry and cargo cult around that three letter word and the machine should not be stopped

[aaronmcadam]

I really enjoyed this talk, but how do we stop domain models getting too big if we should try to move behaviour to them?

[osten_petersson]

zebras are closer related to donkeys actually :)

[botyironcastle]

what if you have huge data like in Post object. I don't think you can init a domain object with that much... looks useless to me when dealing with large chunks of data. Thoughts?

[arthurchia]

Interesting, good talk.
Got another reason not liking global usings 😂

[ChrisAthanas]

This is still all imperative and will always be brittle and hard to maintain

I Like Yegor Bugayenko approach to true AK OOP style

[ahmedameen]

Who's using vs white theme nowadays?

[khanfaizan]

I don't know.. keep it simple.
He over complicated things

[TristanBailey]

Horrible refactor for the sake of possible, it was only about 20lines and could be understood. Now it’s all abstract and pulled in multiple locations.
The ideas he seemed to want to convey could be good. There was no justification apart from a small % to be in own objects as there was no redundancy or over complexity that was improved.
And didn’t add any tests to prove at least more testable. Just did 10 more steps than needed and could have had better example.

[tehklevster]

This is the worst example of code refactoring I've ever seen. Don't think about this unless you have a concern about re-use. Sorry Jimmy.

[deyanvp]

I would have gotten excited about this talk ... 20 years ago ...
My recommendation to current/new generation developers:
- switch to microservices, focus more on the API/contract than internals (and of course avoid sync calls between microservices, try to do as much as possible event-driven etc etc). Consider seriously how to create behavior/capability-focused microservices vs. entity/technical ones (to avoid sync calls as much as possible - no, 100% is not possible)
- switch to immutable data (go functional) separate from logic (forget anemic domain model). And yes, most if not all of the time when you feel it does not feel natural that an entity does something to itself (e.g expires, signs itself), it is really not natural ;)
- keep domain logic well structured and making sure that every function is returning a valid (invariants enforced!) aggregate root
- domain model has no dependency on anything, also not on service interfaces. Forget about double (saw in the code even triple-dispatch with XxxType.CalcuteXxx) - this does not make your code simpler

To add (based on some of the questions below):
- use NoSQL db with 1:1 aggregate root : document mapping (no ORM!, no need for db transactions) for the Write model
- use columnstore index database for the Read model (much faster for complicated queries, you can still use the Write model for simple "get by id" queries)
- to be able to scale differently and have different SLAs: technically seggregate your microservices inside a bounded context as per technical aspects/similar to CQRS, e.g.


(sub interservice events)
(pub interservice events)
(includes Auditing) and even
(for webhooks)