Thread by @refactorfiend

whats the domain in #ddDesign?

the subject matter of the business problem being solved

whats the model in #domainModel?

the pov/ understanding/ comprehension, way of looking at the domain

whats modeling in #domainModeling?

learning about the model by way of discovery techniques like #knowledgeCrunching (like number crunching); event storming; basically asking a ton of questions #madquestionasking; and then capturing the model in some form of living documentation

as a dev, the code works, so why do you even need a model?

so that you, ur boss, the smes and the other devs (all stakeholders) stay on the same page; with the same model i.e. same pov/ understanding and way of looking at and talking about the domain

why does the code need to "sound like" the model?

cus the code is the link between the model n the actual product the users r paying for; if the code is off, then you are short changing the users cus it's likely skewed from their real needs ...

also, the code should "read, feel" like the model

so that you dont add unnecessary cognitive load to smes and other devs trying to extend and maintain your code; the code is the source of truth; the model-in/accuracy of it can mean big $$$ and customer satisfaction long term

why refactor?

as you gain more insight into the domain by continuing to refactor/improve the model and by making small relevant refactorings of the code every time you touch the it, you keep it clean, reducing tech debt, decreasing the chance of code rot

another benefit here is speed; as the model develops and the model/code becomes more in tune enhancements will take relatively less and less time