when you first look at the model, it's a fluffy brown pillow
through the process of modeling you find out it's a hibernating grizzly
this is the importance of modeling i.e. constant refactoring of the comprehension of the domain via knowledge crunching #madquestionasking
you save yourself from building a solution based on the understanding of a pillow, when what the customer really needed was ... whatever you safely handle hibernating bears with?
a good understanding of what youre supposed to code for i.e. the model
1) captures core concepts of the subject matter 2) discards the irrelevant fluff
we achieve it thru asking a lot of questions, having many convos with subject matter experts
why? to produce better code
so if a business rule is called out by the SMEs, then it needs to be called out in the code; not as a few lines or a block within a block of another first class language mechanism, but within its own dedicated mechanism i.e. a method or class
concepts, words, terms, phrases that are called out by the business need to be coded in the relevant class and *called out* by using variables/methods/classes of the same names, words, terms, phrases
sometimes even a block of logic that is simple to understand, is better expressed in the code when factored out into a separate method with a name that expresses the intent of the logic in terms of the domain
e.g.
return a + b; // good
------------------------
int addition(int a, int b) {
return a + b;
}
return addition(a, b); // better
the goal is to bring out the soul of the code
look for the the meaning; the names and terms of concepts and ideas that keep recurring in conversations among the users and SMEs, and make sure that they are expressed in variables, methods, classes, aggregates, patterns, etc
what? you aint know code had soul? 🙃🤖🙏🏾🧞
just make small doable refactorings to the model, design, and or code each iteration
Domain Driven Design (DDD) made plain broke down to the bone gristle. cus i need that science to level up my code, but miss me with all the stuffy acronyms and jargon. 🧵
domain
- the actual problem
- what we're trying to solve with the code for the user
- the set of problems that the users ask the developers to solve
- the subject matter
domain driven
- problem focused
- to stay focused on the actual problem
For me, when the need for a new language, library, framework, shiny thing, etc pops up - i find that i usually take the same general steps
and the 7-bullet list i jotted down in my notes became this thread:
1. pick a language, any language. or framework, library etc.
no tech is perfect. don't sweat it the choice too much. they all have pros and cons - but do try to pick one that has good community adoption so you can get help when you run into blockers
"Always implement things when you actually need them,
never when you just foresee that you need them." - Ron Jeffries
i feel attacked 🙄
(over-abstraction is one of my guilty pleasures) 😅
like, sometimes i'll take that advice to "code to the interface" to the extreme, just cus i can, and i'll make everything an interface. what you can do with polymorphism and dependency injection is fun ...
but man is it an over-abstraction time suck when trying to just focus on "keeping it simple" KISS minimum viable product. gotta draw the line somewhere and make concrete classes and move forward ...