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
www.ndcconferences.com
ndclondon.com/

[@kevinlloyd9507]

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

[@r0shav]

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

[@erril8285]

Amazing talk!! Every Developer should see this!

[@montassarkefi4064]

Thank you for your explanation, great to hear

[@LDdrums20]

That was awesome!

[@NotARealPerson12345]

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.

[@krccmsitp2884]

Simply great and inspiring!

[@wokker2]

Learned some new Rider/Resharper tricks :)

[@finch9668]

Amazing!

[@Dimestel]

Amazing example how to cook it!

[@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.

[@Weexow]

Wouldn’t that be signer.Sign(document, service)

[@marna_li]

@@Weexow Good point! I guess that it depends on how you view it. What is the center of your model. But I would consider your solution if there were a Person/User concept. Because the Person signs the Document using the SigningService.

[@NaaneVinu]

​@@marna_li I feel that, in that sense still it could have been like, the service/class that is responsible to create the document, uses the signing Service to sign the document the document.

[@mahdimollaeian8840]

where can i download project source code?

[@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?

[@aaronmcadam]

How can we avoid God Classes if we want to avoid anaemic domain models?

[@ioanadobos2840]

@@aaronmcadam maybe value objects and constant reiteration over the model I'm guessing... also when a model gets too big it's a sign it does too much and maybe we should think about spliting it. If anyone thinks about something extra I'm really curious too about other solutions

[@aaronmcadam]

@@ioanadobos2840 yeah I think delegating to other classes might help keep the complexity down, but it’s still tricky to balance these things 😅

[@vin2629]

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.

[@osten_petersson]

zebras are closer related to donkeys actually :)

[@botyironcastle]

what if you have huge data like 100000000comments 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?

[@iorch82]

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

What do you do to organize microservices and modular monoliths if not in Bounded Contexts?

[@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

[@khanfaizan05]

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.

Would love to see you doing an hour-long live demo covering all these topics on a non-contrived, fully-tested codebase

[@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.

[@ChrisAthanas]

Accurate Imperative code masquerading as OOP is inherently unsustainable and un-maintainable mess I prefer Yegor Bugayenko approach

[@TristanBailey]

Exactly. And never even ran the code or tests to prove any of this helped and didn’t break the use of the methods!

[@nickbarton3191]

​​@@ChrisAthanasQuite ! I'm following Zoran Horvat, rich domain models. I'd like to find an example of turning imperative legacy code into a rich domain model, stepwise not to break stuff.

[@cd1131]

Strongly disagree. This helps big time to correctly represent the business domain and avoid unmaintainable spaghetti code. It produces very comprehensible unit tests making it easy to get the logic right. Always consider this unless you are working on hello world projects or just CRUD API’s.

[@bayobizzle]

​@@ChrisAthanasany link to the Bugayenko approach you mentioned?

[@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. IdentityVerification-QueryHandling IdentityVerification-CommandHandling IdentityVerification-EventHandling (sub interservice events) IdentityVerification-EventPublishing (pub interservice events) IdentityVerification-ChangeHandling (includes Auditing) and even IdentityVerification-ExternalEventPublishing (for webhooks)

[@arunnair7584]

I found microservices drastically reduces the app's performance (when used with kafka). Also unless you have multiple teams working in multiple languages, do you see any significant benefits?

[@namewastaken360]

A very good talk that ties together a lot of these ideas is Scott Havens talk at DOES19. Here's a recording kzbin.info/www/bejne/fKTOepVviMaln6s

[@RealMathewAdams]

@@arunnair7584 No, the team structure is one that is the deciding factor of when to use microservices. It solves a problem of developer velocity (delivery) among very large and coordinated teams. People prescribe microservices and gloss over the many, many, problems they introduce.

[@deyanvp]

​@@RealMathewAdams I beg to differ. In my context every individual developer can develop a microservice by himself (and every deveper owns more than 1 microservice for sure). And even if I was developing the whole solution by myself, I would still go for microservices, as the possibility of deploying small pieces of the whole is an extremely precious capability when it comes to CD and deploying small changes all the time. Note that my recommendation is not only to split your solution into services, but also to split every service into microservices as per CQRS, which I have briefly touched upon at the end of this article: dev.to/deyanp/tbd-current-state-last-event-as-an-alternative-to-event-sourcing-5gm5. But of course, for microservice architecture one has to learn new tricks (already mentioned sync calls vs. event-driven), which are not necessarily what was taught in the past 20 years ...

[@arunnair7584]

@@deyanvp Do you implement transactions across microservices?

[@mahdimollaeian8840]

That was awesome!