Discover and read the best of Twitter Threads about #softwaredesign

object oriented programming is where you design each element in your code, based on rules around making well-formed classes and objects; we say domain driven design, based on "modeling the domain", is oop done right:

basically that means - solving the right problem

domain driven design produces higher quality software; it's about #domainModeling

which is basically #understandingTheProblem that the users want solved

3/3 cus who wants to go to work to hack away at some code that's not even solving the right problem

#objectOrientedProgramming #domainDrivenDesign #domainModeling #softwareDesign #codeNewbies

The progression from coding to designing architectures is the practice of refactoring the structure and behavior of elements, at increasingly higher levels of scale.

#softwareDesign #softwareArchitecture

... where system elements can be

field/ var/ param -> method/ function/ procedure -> class -> aggregate/ composite/ collection -> module/ package -> application/ service -> sub-system -> system -> system of systems

#codenewbie #systemDesign

... where at each level of scale, the goal of refactoring is to win the trade-offs between time, cost, quality

#architects #management #visionary #leadership

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

so you think you can architect

#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

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

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

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

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

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 ✌️🏾

think loose coupling and high cohesion of concepts before that of classes

#softwareDesign #standaloneClasses #dddRefresher

you want #looseCoupling. standalone classes are a good thing. generally, the more of them you have in your design, the better it is in the sense it'll be easier it is to understand.

in designing your class, try to minimize the dependencies you have to other classes to zero if possible; keep these as primitives wherever it makes sense:

- field types
- method param types
- method return types
- types of local variables in methods
--- any other kinds?

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

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

Read 8 tweets