Discover and read the best of Twitter Threads about #ooDesign
Most recents (8)
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
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
just sharing a design decision i gotta make while doing this enhancement/refactoring
a) use a basic constructor
b) use a *Builder
which to use and when? 🤔
#ooDesign #ddDesign #builderPattern
a) use a basic constructor
b) use a *Builder
which to use and when? 🤔
#ooDesign #ddDesign #builderPattern
im going with the basic constructor, pluggin in all the params i need to make the obj "whole"
theres just not enough going on in the init of the obj to justify bustin out a whole Builder for it
i do have an invariant/rule-validation to carry out during inits, but it's just a trivial conditional
i do have an invariant/rule-validation to carry out during inits, but it's just a trivial conditional
