Domain-Driven Refactoring - Jimmy Bogard

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.

[@GintsPolis]

Do you think this code gets easer to read and will run faster, after changes made 19:35 and forward?

[@balazs.hideghety]

It is. Extracting methods, and replacing the 3-5 line code with a meaningfully named function results later in much easier (and less) readability when we're looking for errors. But probably the biggest achievement is found when he makes members private and creates constructors for some of the objects and this place: kzbin.info/www/bejne/oYCWfX19l7ZmgKc - this part is extremely important, as until NumberOfActiveOffers is public and changeable from anywhere in the code, it's too easy for someone to mess up that data (same for the read-only list of AssignedOffers).

[@GintsPolis]

@@balazs.hideghety that is done till 19:35. Further it gets more difficult to read.