https://git.mleku.dev/mleku/smesh/src/branch/master/DDD_ANALYSIS.md

nostr:npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl i am forking jumble because i have lots of time at the moment and first thing i wanted to do before changing anything, was get a domain driven design analysis done. i will leave this in the repo where you see it now, you might be interested to read it or at least skim it.

nostr:npub1m4ny6hjqzepn4rxknuq94c2gpqzr29ufkkw7ttcxyak7v43n6vvsajc2jl also, i know you know some stuff about various dev/design/architecture modalities, this is how things are done with DDD

just from first few screenfuls i can see a lot of things that i've noticed with other front end projects, especially the anemic domain model. in my own code i have for quite some years tended towards making a mess at first, and then after i find myself with several 400+ line functions, i go hard on refactoring, moving types that seem to live together into their own packages, and so on, and for which reason you can see here:

https://git.mleku.dev/mleku/next.orly.dev/src/branch/main/DDD_ANALYSIS.md

which was the state of orly until a few days ago (shortly after that was committed) that it evaluated my work pretty good, first it was 7, then after cleaning up the complexity of the 600+ line event handling code, i got upgraded to 7.5, still lots more to do.

i also applied it to the plebian-signer (forked from nostr:npub1qdjn8j4gwgmkj3k5un775nq6q3q7mguv5tvajstmkdsqdja2havq03fqm7 's gooti - i think he wrote that?) and here is the analysis of the codebase, after i added a ton of features, i wanted to get it cleaned up:

https://git.mleku.dev/mleku/plebeian-signer/src/branch/main/DDD_ANALYSIS.md

the signer, in particular, became noticably more performant after applying all of the recommendations in that document, and when i fully complete orly, i think it will also improve, though i have also added a new skill to https://next.orly.dev which is about go memory management and scheduling (just look in the .claude/skills directory). for go, there is some specific architecture to memory management, and what types go on the stack, what goes on the heap, and how to reduce allocations on the heap, and move stuff, especially stuff that the DDD analysis should be immutable, onto the stack, where it is very cheap pass by value (ie, copy) and thus enforce effective mutability with minimal cost.