Domain-Driven Refactoring - Jimmy Bogard - NDC Porto 2022
Vložit
- čas přidán 6. 07. 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
ndcporto.com - Věda a technologie
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,
Nice thoughts. What would you suggest to read/watch to get OOP concepts correct ?
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`.
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.
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.
Good one!! Thanks!
Awesome !!!
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.
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)?
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.
You can actually declare functions into an enum using an extension method. It's not 100% clean, but at least the usage feels right 😉
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.
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.
You can (and you should) manage without domain-modelling If you are dealing with a simple CRUD, transaction scripts should be enough.
aligned language (programming/users/stakeholders) is a very interesting idea but only available in english speaking contexts
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.
Good ADV for Resharp. All refactoring without one test. bad bad bad.
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
they are not DTO classes, they are entities, which owns data and behavior.
No sound :(
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.
So watch again and focus
@@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".
Awesome !!!