Domain-Driven Refactoring - Jimmy Bogard - NDC Porto 2022

[@marna_li]

Great talk! What I have learned from experimenting domain-driven design is that , once you get into this mindset of thinking about the domain and how to model it, everything just gets easier to implement and refactoring is not a big deal. In my view, a good software project is less about the implementation details and more about the rules. Good abstractions makes it easier to reason about your software and change it if needed. It also leads to better quality of the software, both code and reduction if bugs. But I find that a lot of people still want separation of logic and data and a lot of abstractions just because that is what they think software should look like. Most don't even understand OOP and just write classes, which are not the subject of OOP! Getting these people to start look into Domain-driven design is hard, because it would have them to think non-technically with regards to programming - how to reason about the domain not from the point of code, but to model it to represent the domain. Still I encounter programmers who start coding without modelling. Perhaps it is the culture,

[@MakeItStik]

Nice thoughts. What would you suggest to read/watch to get OOP concepts correct ?

[@VoroninPavel]

There's one more thing Jimmy probably had no time to mention. But after operations are moved into domain objects, we can start publishing domain events. For example, `OfferAssigned`, `OfferExpired`.

[@marna_li]

I think that was out of scope. Event-driven design is perhaps not the first thing to look into when being a beginner. I have met some resistance to it because it is not just small topic. Grasping all the concepts of domain-driven design has taken me some time experimenting and reading.

[@judas1337]

That sounds like a reason to do this refactor. As Bogard states, he probably would approve a pull request with the original code. So to motivate this refactoring something more is needed. Being able to publish domain events could be that reason.

[@peteruelimaa4973]

Am I right that this packing logic into entities is kind of the opposite approach to what functional programming languages use (data is immutable and functions operate on that data)?

[@pedrobettt]

You can do a lot of this while remaining functional, as long as you make the functions entity-specific. You'd just replace the mutation of data with a whole new object instead, containing the values you'd have changed.

[@rodelias9378]

Good one!! Thanks!

[@MaxCervantes1984]

I would probably encapsulate the offerValueCalculator and cancellationToken inside a delegate. Something like Func calculateOfferValue. That way I can get rid of the cancellation token on the AssignOffer signature.

[@sebastianpopa4778]

gave up after 20min. Started with a piece of code which was simple and readable, at 20min in was something else alright. Also, I missed the "DDD refactoring", this is just "refactoring", maybe the DDD part is later in the video

[@marcotroster8247]

You can actually declare functions into an enum using an extension method. It's not 100% clean, but at least the usage feels right 😉

[@kostasgkoutis8534]

True but I think he had in mind going for enumeration classes that would cause issues with persisting them to the db. It can be done of course, but it would take him way longer to write it out.

[@sachinjain9165]

Awesome !!!

[@iliyan-kulishev]

Is it safe to say that if you are not dealing with complex business logic you don't need a domain layer? I'm developing a system that really looks somewhat like this one before the refactorings and it works.

[@TheHabibass]

You can (and you should) manage without domain-modelling If you are dealing with a simple CRUD, transaction scripts should be enough.

[@madskaddie]

aligned language (programming/users/stakeholders) is a very interesting idea but only available in english speaking contexts

[@RemcoPeggeman]

A work-around that worked best for us is to agree on the domain language with the business (in the original language) and document a set of translations (in English) within the developer team. We did that in a glossary format in Notion where we created a table with Original Word, Meaning, Agreed upon Translation.

[@oloidhexasphericon5349]

I don't understand the whole point of doing this at all !! Aren't DTO classes just supposed to have properties like POCO s ?? (DBModel -> DT0 -> ViewModel ) Why are we putting business logic inside them ?? We could just create more service classes to extract the webrequest and extra stuff. Also which 'domain' should handle which part of the logic seems to become less clear. With more services, we break down services till they do only that 1 piece of logic

[@GuilhermeNeubaner]

they are not DTO classes, they are entities, which owns data and behavior.

[@stefanotorelli3688]

Good ADV for Resharp. All refactoring without one test. bad bad bad.

[@RajaKajiev]

Sorry, but I've lost the point of all those renamings and moves and renamings and moves and renam.... somewhere in the middle of the talk.

[@m4r10x2]

So watch again and focus

[@RajaKajiev]

@@m4r10x2 sorry, but I don't want to waste my time watching JetBrainz promo one more time. That guy (J.B.) has tons of live coding sesions, which are more meaningful than this ad "talk".

[@zdabka]

No sound :(

[@mansoursepehrjoo7568]

Awesome !!!