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
...
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
Read 3 tweets
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
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
Read 5 tweets
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 ...

👇🏾
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 ...

👇🏾
Read 7 tweets
tell me about the concepts and the contexts before you try to sell me on the tech

#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 ...
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
Read 3 tweets
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
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 - 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
Read 8 tweets
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
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
Read 13 tweets
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
Read 8 tweets
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
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
Read 5 tweets

Related hashtags

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!