Thread by @refactorfiend

one of the best parts of development, even more fun than solving algorithmic riddles, is

discovering and turning new or hidden concepts into objects, along with the relationships between it and other objects (pieces of data and behaviors on data)

#ddDesign

or as E.Evans put it in the blue book - making implicit concepts implicit

it's fun, but it takes effort from devs and subject matter experts collaboration to make it happen. takes a culture of patience, curiosity, flexibility to mine for these implicit concepts out of the ubiquitous language

if you listen closely to the way the business describes a problem or process you can discover implicit nuances of behavior that you can bring out and make explicit in the code

how does code speak?

through #intentionRevealingInterfaces, #meaningfulNames of classes and methods/functions. through different kinds of classes and constructs/#designPatterns e.g. Value, Entity, Service, Aggregate, Repository

if a word or term or phrase exists in the ubiquitous language, make sure it exists in the code, or else the code will become divergent from the actual practical subject matter that we are trying to address in the software

refactoring on the concepts, in this iterative way, youll find gaps in the code where the language is not being expressed enough

when one insight is revealed it has a way to uncover a bunch of other ones behind it, lighting up the collective understanding of the subject matter (#domainModel) even more

weirdness, awkwardness, contradictions, things that just feel off in a design or in the code usually means its a goldmine for digging out these kinds of eye opening breakthrough concepts that improve the design and the software you can produce

your shovels - #knowledgeCrunching #madQuestionAsking #eventStorming ... dig away so you could drop those jewels into the codebase

why are we doing all this? this daily weekly collaborative back and forth between dev/s and sme/s?

cus we want our code to be accurate; about the business processes it claims to implement or support; leading ultimately to a better product, less WTFs, and lower maintenance costs

it helps to read; do your googles, read books or documentation on your business domain; youll become more familiar with the concepts so that you can ask better questions about the existing model/ design/ code

there's a lot of trial and error in the modeling designing coding process.. thats not a bad thing it's all in a days work for a dev.. many conversations, iterations, refactorings

they call it software for a reason; it's supposed to be soft, malleable, easily changeable, easily refactorable

#devcommunity #devdiscuss

@threadreaderapp unroll

concepts, words, terms, phrases that are called out by the business need to be coded in the relevant class and *called out* by using variables/methods/classes of the same #meaningfulNames, words, terms, phrases

if the business smes use a certain vocabulary when talking about the solution,

then the code needs to use the same vocabulary conceptually the same way