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

design

- code
- to arrange the code so that it solves a problem
- the code setup that solves the users' problem

domain driven design

- coding to solve the users' actual problem not to geek out on tech
- making all coding decisions based on the actual problem
- keeping the code in line with the actual problem
- problem focused coding
- tech for the users' sake

#ddDesign

the usual stress

- anti-domain driven design
- coding to geek out on the language, framework, ide, buzzword
- making all coding decisions based on the new tech buzzword
- keeping the code dipped in the new shiny tech
- coding for teh tech
- tech for tech sake

ddd benefits

code that:
- reads the way the users talk about the problem
- shows how each line directly helps the user
- makes sense to read; that doesn't look like pure geek-speak
- is as changeable/flexible as your understanding, ideas, pov of the business

ddd benefits (cont)

code that:
- is accurate and directly related to the users' problem
- is rich in meaning to current devs and future devs
- becomes legacy code that future developers will love
- is valuable even after the original tech, framework, platform has come and gone

rave n rant side bar

don't let the the tech interview quizzes, the job descriptions, the gatekeeper shit fool you

the whole point of coding is to solve the problem that the users want solved.

users don't gaf about code or fizz buzz or k8s. they want their problem solved

the code (lang, ide, framework, platform, buzzword, etc) is not the point - it's just the tool

the code != the subject matter != the problem != the point

solving the users' problem is the whole point of all the coding and tools

the blue book

"Domain Driven Design Tackling the Complexity in the Heart of Software" by Eric Evans

btw if yall havent already read the blue book aka the ddd bible, please do yourself a favor and go cop that https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/ref=sr_1_2?crid=2RN5SX28XVFMI&dchild=1&keywords=ddd+book&qid=1603056666&s=books&sprefix=ddd%2Cstripbooks%2C263&sr=1-2

not for nothing

"Domain-Driven Design Distilled" by Vaughn Vernon

aka the green book, is another one. i aint read it yet, but Vernon is a good dude that i actually got to build w/ a bit on twitter, and people rave about it https://www.amazon.com/Domain-Driven-Design-Distilled-Vaughn-Vernon/dp/0134434420/ref=pd_sbs_14_5/134-8993591-5429520?_encoding=UTF8&pd_rd_i=0134434420&pd_rd_r=16a36913-aea0-46dd-849f-4f64e14b8a9f&pd_rd_w=z4PHU&pd_rd_wg=26JJL&pf_rd_p=b65ee94e-1282-43fc-a8b1-8bf931f6dfab&pf_rd_r=QWJ84PQX6R6Y6WWD03P2&psc=1&refRID=QWJ84PQX6R6Y6WWD03P2

ok but back to it. so that breaks down the basic whats and whys of Domain Driven Design, with hopefully a lot of the jargon made plain. but there's of course a lil bit more to the science...