Thread by @refactorfiend

sometimes the kind of refactoring that clears the way for easier extension, is not a refactoring toward this or that design pattern, but a refactoring to support a deeper conceptual understanding of a functional use case/ user scenario

#conceptualContours #ddDesign

oh you refactor refactor 😅

study and understand a user scenario or business process; then model and design their concepts

think of principles like high cohesion and low coupling, but in terms of concepts first, then classes and code mechanisms

#ddDesign #softwareDesign

"Refactoring toward deeper insight" - E. Evans

"refactoring concepts into code" is an ongoing process, it doesnt happen in a day, a week or a month; but to me it's the most enjoyable part of this grind we call coding

#refactoring #softwareDesign

basic example:

if your domain understands "foobar" and not "foo bar",

then the code should probably have one method
foobar(), as opposed to foo() and bar();

even though the latter may be following some legit technical design move like "extract method" or something

decompose your methods, classes, aggregates, etc, not according to teh tech or design patterns primarily, but in close relation to how domain use case concepts are actually understood at the core, in the domain

so teh tech should conform to the concepts (of the domain i.e. business subject matter), not the other way around; flutter or react or spring or kubernetes or whatever tech, should all bow to whatever problem you're solving in the domain