Discover and read the best of Twitter Threads about #DDDesign
Most recents (24)
Nick Tune now on stage #newcrafts 
I just talked with a very good friend working as Senior Engineer about what I would recommend him to learn as the next steps.
He is quite a product-mindset person. He is genuinely interested in why we do things from a customer perspective.
So, next steps? ...
1/13
He is quite a product-mindset person. He is genuinely interested in why we do things from a customer perspective.
So, next steps? ...
1/13
To have a more significant impact on the products, I suggested learning about:
- Fast Flow of Change with @TeamTopologies
- Situational Awareness with #WardleyMapping
- Domain Modelling to support Fast Flow of Change with #DDDesign
2/13
- Fast Flow of Change with @TeamTopologies
- Situational Awareness with #WardleyMapping
- Domain Modelling to support Fast Flow of Change with #DDDesign
2/13
Learning those points can unlock a new way to understand how _Value is delivered_ and why/how socio-technical systems impact a product, team, and business.
Moving from my impact as an individual to how the system impacts and how I can influence to the overall organization
3/13
Moving from my impact as an individual to how the system impacts and how I can influence to the overall organization
3/13
The first time I built a CQRS system… it was in 2006. The term hadn’t be coined yet by Greg (that happened in 2010), but the practice was ubiquitous in finance with tons of high throughput platforms to build or to maintain.
Actually, the first time I’ve used this architecture style was not due to my young skills of tech architect, but rather on a technical constraint.
Why do I practice #tdd you ask?
There’s a number of paths I could’ve taken (or combinations of the four).
1) Write no automated tests.
2) Write tests before writing code.
3) Write tests at the same time as code.
4) Write tests after writing code.
🧵
There’s a number of paths I could’ve taken (or combinations of the four).
1) Write no automated tests.
2) Write tests before writing code.
3) Write tests at the same time as code.
4) Write tests after writing code.
🧵
On a project that’s worth practicing #DDDesign, having no tests is not an option. Continuous refactoring towards deeper insights is the foundation of #DDD and it’s too scary to refactor with no tests.
As a result, refactoring won’t happen without tests and code will rot. Over time our code and our understanding of the domain will either diverge, or we’ll stop looking for insights to avoid change.
In Implementing #DDDesign why use Anticorruption Layer rather than a Repository to integrate with another Bounded Context?
Typically the Repository pattern is used as an Adapter in front of a database. In general you could think of a Repository as an AcL over a database. 1/6
Typically the Repository pattern is used as an Adapter in front of a database. In general you could think of a Repository as an AcL over a database. 1/6
But then again, an AcL is at least both of these: (1) an Adapter, and (2) a Translator. Typically a Repository doesn't translate from database data into a model's data. Usually database data is at most reshaped when hydrating 2/6
models. In other words, you think of an AcL more as a translator between two different model languages, where one language might not be carefully defined. A Repository isn't translating between languages, just adapting database data shapes to/from domain model data shapes. 3/6
This is my interpretation of what a Bounded Context means: a bounded context restricts (or BOUNDS) the interpretation of the important terms in the domain (hence providing a CONTEXT), thereby making one model internal to that boundary consistent.
This is core to why some members of the #DDDesign community refer to the Bounded Context as a linguistic boundary: by restricting the interpretation of the domain-specific terms to one consistent meaning it thereby defines one dialect of the Ubuiquitous Language
The model that the Bounded Context contains, can be implemented in code (or not!), but importantly, this boundary will be visible somewhere. The explicit nature of the boundary in our system is a key aspect of its ability to provide utility.
This nonsense that tactical #DDDesign isn't important has to stop. It's not even an actual opinion anyone has given proper thought, it's just a fashionable meme people are parroting. None of your strategic design matters if nobody in your org can properly implement it.
If you think tactics don't matter, you might as well wear a t-shirt saying "Ivory tower architect 4 life".
(Yes I deliberately deployed one overused meme to battle the use of another, I'm a sly fox.)
Last week I received an interesting response to my cardboard #dddesign thread. It inspired me to write another one.
A thread on why some problems aren't worth your time and effort. (1/13)
A thread on why some problems aren't worth your time and effort. (1/13)
First, if you didn't read the original thread (2/13)
. @usdzshare says that instead of messing around with cardboards, the problem could be solved using a LiDAR equipped device + augmented reality app. What does it have to do with domain-driven design (#dddesign)? (3/13)
What do you see in the picture? A piece of cardboard? Some junk? No! — It’s a model!
Thread on models and bounded contexts 1/9
#DDDesign #BoundedContext
Thread on models and bounded contexts 1/9
#DDDesign #BoundedContext
It’s a model of the Siemens KG86NAI31L fridge. The cardboard doesn’t look anything like the fridge? — That’s true but not important. A model is not a copy of a real-world entity but a construct supposed to solve a problem. 2/9
Hence, the correct question to ask is: what problem does this model solve? In our apartment, we have a weird entry to the kitchen. The cardboard’s is in the size of the fridge’s width and depth, and the problem it solves is checking whether it can make it through the door. 3/9
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
- 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
- problem focused
- to stay focused on the actual problem
Everybody wants less bugs in their code but nobody wants to _______.
use #vscode 😅
declare variables right before they're used
the culture is more important than
the org chart is more important than
the subject matter expertise is more important than
the code and design is more important than
teh tech stack/language/framework/etc
...
the org chart is more important than
the subject matter expertise is more important than
the code and design is more important than
teh tech stack/language/framework/etc
...
in other words:
the cultural architecture is more important than
the org architecture is more important than
the conceptual architecture is more important than
the technical application architecture is more important than
the technical infrastructure architecture
the cultural architecture is more important than
the org architecture is more important than
the conceptual architecture is more important than
the technical application architecture is more important than
the technical infrastructure architecture
so you think you can architect
#conwaysLaw #asAboveSoBelow #ddDesign #ooDesign #softwareDesign #softwareArchitecture #domainDriven #techAgnostic
#conwaysLaw #asAboveSoBelow #ddDesign #ooDesign #softwareDesign #softwareArchitecture #domainDriven #techAgnostic
on an agile team, whenever someone uses the word "story" and "requirement" to mean the same thing, an angel loses her wings
how do you point out the benefits of using one over the other?
"story" frames with problem, with the person at the center
"requirement" focus on the product, teh soul-less tech
"story" frames with problem, with the person at the center
"requirement" focus on the product, teh soul-less tech
it's better to talk about the user, the user scenario, the actual problem, (the domain), than it is to base your work on clever algorithms and hyped up, buzzwordy shiny tech
i been calin it the #dddfl for kicks - the domain driven design feedback loop
ubiquitous language <-> domain model <-> design <-> code
ubiquitous language <-> domain model <-> design <-> code
now i think team structure needs to be in it to account for conways law 🤔
getting crazy pushback 'gainst knowledge crunching n other #ddDesign habits. methinks def due to org culture;
getting crazy pushback 'gainst knowledge crunching n other #ddDesign habits. methinks def due to org culture;
so new ish:
ubiquitous language <-> team structure <-> domain model <-> design <-> code
#dddfl
refactor one part, refactor all parts
ubiquitous language <-> team structure <-> domain model <-> design <-> code
#dddfl
refactor one part, refactor all parts
one way to look at it is that #domainDrivenDesign is the union of technical #objectOrientedDesign tightly coupled with subject matter expertise, business analysis and modeling. #ddd is #ood with soul. #ddDesign is #ooDesign done right
in complex systems, or enterprise development
different people/teams may have different
povs/ models/ experiences/ conceptualization/ understandings
of the subject matter or problem to be solved, and ...
👇🏾
different people/teams may have different
povs/ models/ experiences/ conceptualization/ understandings
of the subject matter or problem to be solved, and ...
👇🏾
they dont realize that there are these different povs; and even if they do,
they dont see the danger of coding to different concepts as long as it "works"; so inevitably ...
👇🏾
they dont see the danger of coding to different concepts as long as it "works"; so inevitably ...
👇🏾
tell me about the concepts and the contexts before you try to sell me on the tech
#softwareDevelopment #softwareDesign
#softwareDevelopment #softwareDesign
when describing a system, we devs and archs, usually focus on the tech stack; sometimes we'll touch on the short term technical milestones; we'll rave and ramble on about kafka, graphql, kubernetes, react, django or whatever;
and that stuff's all cool, but i care more about ...
and that stuff's all cool, but i care more about ...
the one liners you'd give non tech stakeholders that answer?:
a) what does the system do?
b) what/who is the core downstream sub/system, user?
c) upstream
unpopular pov? but, it's just more fun to conceptualize those things first
#domainDriven #ooDesign #ddDesign
a) what does the system do?
b) what/who is the core downstream sub/system, user?
c) upstream
unpopular pov? but, it's just more fun to conceptualize those things first
#domainDriven #ooDesign #ddDesign
overlooked but obvious signs that your dev team might be struggling with implicit differences in povs with another team (implicit model context diffs)?
- coded interfaces don't match up
- unexpected functionality/bugs pop up
- confusing unproductive discussions and meetings
- coded interfaces don't match up
- unexpected functionality/bugs pop up
- confusing unproductive discussions and meetings
when you un/intentionally try to intersect two sets of povs/concepts that are subtly different from each other, you get:
- duplicate concepts
- false cognates
- duplicate concepts
- false cognates
duplicate concepts - i.e. two classes in two different places, that represent the same concept; you get all the problems of WET code; have to worry about making changes in two places; and having to keep em in sync; but because the diff; non DRY
hard or soft code and design? that is the question. and welp, there's a reason we call it "soft" ware
the soft in software means that the code and design must be malleable and durable
- malleable code is easy to change/refactor without having to jump many dependency/build/compilation hurdles
- durable code is easy to change/refactor without breaking other parts of the code
- malleable code is easy to change/refactor without having to jump many dependency/build/compilation hurdles
- durable code is easy to change/refactor without breaking other parts of the code
the design ninja masters and even doting design stans like myself talk about "good" solid design, and about supple and strategic design (#ddDesign). design that elicits high UX for other devs i.e. DX (@CarlosRucker); regardless of paradigm i #ooDesign #functionalProgramming, etc
yea the bug shows up in the code, but many times the root cause of the bug is not the code, not even the design or the requirements, but the model i.e. your conceptualization of the domain
consider that you could be burning all that time on fixing that bug, when the root problem's not the bug, but a misunderstanding of the subject matter being coded to
the real bug could be in how you understand or how you look at the subject matter; could be a misaligned point of view or a missing concept that's unknown or not brought out explicitly in conversations with the subject matter experts and in turn, overlooked by devs
why are analysis patterns not as popular as design patterns? i.e. template models to be tweaked per your particular domain modeling endeavor; "a kit of model fragments" (E.Evans);
they remove the need to reinvent the wheel e'ytime you need to model a domain. like a framework or library of concepts. like a react/angular/springboot for model concepts? not the best analogy but it'll do 🤓
Analysis Patterns: Reusable Object Models by Martin Fowler) martinfowler.com/books/ap.html
i used to think programming was all math and algorithms. but once i started to think about design and architecture more like like graphic design, poetry and sculpture it made it much less intimidating and much more fun to approach any design challenge
#ddDesign #softwareDesign
#ddDesign #softwareDesign
this is why i am a domain driven design fan. i forget who said it but it's true. DDD is OOD done right. i think it's is the kind of paradigm that allows a more artistic view due to the abstraction, modularization, and other principles inherent in OOD. but i digress ...
... but anyways yea where are my kindred "software development as art, craft, poetry, sculpture, portraiture, design" ppls? shiiyt it's hard enough to find other back end devs on here so i aint holding my breath 🤷🏾♂️😅 .. still ill be over here hyped off of design... get at me ✌️🏾
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
#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
think of principles like high cohesion and low coupling, but in terms of concepts first, then classes and code mechanisms
#ddDesign #softwareDesign
i'd even throw in the modifiers:
- adjectives (informs types of nouns/things/data)
- adverbs (informs ways or degrees of verbs/behaviors)
(at this point you only have a shallow view of the design)
(but it's a good start)
- adjectives (informs types of nouns/things/data)
- adverbs (informs ways or degrees of verbs/behaviors)
(at this point you only have a shallow view of the design)
(but it's a good start)
then get deeper, keeping track of the concepts':
- associations
- relationships (e.g. one/many to one/many)
- roles
- dependencies
(now we're diggin, getting to the essence of the domain)
- associations
- relationships (e.g. one/many to one/many)
- roles
- dependencies
(now we're diggin, getting to the essence of the domain)
whats the model in #domainModel?
the pov/ understanding/ comprehension, way of looking at the domain
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
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
