Discover and read the best of Twitter Threads about #dddesign

Jakub Zalas

@jakub_zalas

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.

🧵

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.

Read 17 tweets

Vaughn Vernon

@VaughnVernon

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

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

Read 6 tweets

Savvas Kλeanthous

@SKleanthous

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.

https://twitter.com/SKleanthous/status/1447934156252536839

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.

Read 4 tweets

Mathias Verraes

@mathiasverraes

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.)

Read 27 tweets

Vladik Khononov

@vladikk

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)

https://twitter.com/usdzshare/status/1339673586278178817

First, if you didn't read the original thread (2/13)

https://twitter.com/vladikk/status/1335947978482339841

. @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)

Read 13 tweets

Vladik Khononov

@vladikk

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

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

Read 9 tweets

Rusiim Shabazz { design(); refactor(); }

@refactorfiend

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

Read 122 tweets

Rusiim Shabazz { design(); refactor(); }

@refactorfiend

Everybody wants less bugs in their code but nobody wants to _______.

use #vscode 😅

declare variables right before they're used

Read 23 tweets

Rusiim Shabazz

@refactorfiend

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

Read 3 tweets

Rusiim Shabazz

@refactorfiend

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

Rusiim Shabazz

@refactorfiend

i been calin it the #dddfl for kicks - the domain driven design feedback loop

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;

so new ish:

ubiquitous language <-> team structure <-> domain model <-> design <-> code
#dddfl

refactor one part, refactor all parts

Read 5 tweets

Rusiim Shabazz

@refactorfiend

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

Rusiim Shabazz

@refactorfiend

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

Rusiim Shabazz

@refactorfiend

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

Rusiim Shabazz

@refactorfiend

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

Rusiim Shabazz

@refactorfiend

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

Rusiim Shabazz

@refactorfiend

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

Read 9 tweets

Rusiim Shabazz

@refactorfiend

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

Read 3 tweets

Rusiim Shabazz

@refactorfiend

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

Rusiim Shabazz

@refactorfiend

software modeling and #ddDesign, quick intro

for starters, model basic concepts:

- nouns
- verbs

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)

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)

Read 7 tweets

Rusiim Shabazz

@refactorfiend

whats the domain in #ddDesign?

the subject matter of the business problem being solved

whats the model in #domainModel?

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

Read 8 tweets

Discover and read the best of Twitter Threads about #dddesign

Most recents (24)

Related hashtags

Discover and read the best of Twitter Threads about #dddesign

Most recents (24)

Related hashtags

Did Thread Reader help you today?