๐๐พ in order to capture, understand, implement domain nuances, separate the unified model into new ones in it's own bounded context
๐๐พ decompose models/contexts
- by teams' makeup/composition
- by transactional consistency
- by business processes/ behaviors
๐๐พ embrace refactoring/ refinement of the model as domain insight deepens
๐๐พ event and message driven asynch archs are paradigms that can decouple your bounded contexts
that 300 analogy regarding commands ๐
types of messages
- events - use between contexts
- commands - use within contexts
๐๐พ contexts dont bully each other with commands darn it, they send event messages
๐๐พ event sourcing/modeling is not a silver bullet
you dont all of a sudden get clean well designed
loosely coupled maintainable scalable architecture for free
careful about the event messages you pass from one context to the other
- thoughtfully design your event message data structures
- consider of how/what state information is passed
๐
"Friends don't let friends do distributed transactions" - Indu Alagarsamy
sessions of SMEs collabing on identifying events and their constraints in a business process or system, with a goal to visually skecth out the domain model
events to commands
i.e. associate commands to appropriate events that
perform corresponding business process behaviors
and validate corresponding constraints
"you are deleted!" ๐
"All models are wrong, but some are useful." - George Box
be ruthless about coding the domain model concepts in the ubiquitous language and embrace refactoring and continuous improvement/refinement
i'll def do some study on these concepts
- temporal coupling
- autonomous decisions
- transaction rollbacks
this should be obvious to most experienced software professionals, but it bears repeating:
๐ข there is no single software paradigm that is a silver bullet solution for all software problems ... not OOP, FP, dist archs, monolith, ES, CQRS, TDD, etc, etc. theres always a tradeoff
to say otherwise, imho, is just politicking an agenda or bias
friends dont let friends
go into production without cicd
streamlined like a well oiled push button machine
โข โข โข
Missing some Tweet in this thread? You can try to
force a refresh
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 ...