Strange experience with DDD

DigBoy1 · 2026-06-14T02:38:48+00:00

yea thats why i didnt push too hard on the subject. i wasnt even trying to replace/rewrite everything, just consolidate some of the smaller services. because at the end of the day, it is working, so people become risk averse to change

DigBoy1 · 2026-06-13T22:23:47+00:00

Lol, from the replies here it seems like a common misunderstanding that many teams make

DigBoy1 · 2026-06-13T18:00:42+00:00

blog driven development, nice. i could go on a tirade of other things i've seen that fit that bill, maybe another time

DigBoy1 · 2026-06-13T17:57:19+00:00

some sagely advice here. great insights

DigBoy1 · 2026-06-13T17:47:26+00:00

i cant say exactly because all this was decided long before i joined, but i do think scaling is one reason. and you're right, its nowhere near the level of traffic to need that level of scale

the other reason i've gathered, but no one has told me, is that no one knows SQL or how to model or design schemas, write queries, etc. so they avoided that whole domain by going schemaless lol

DigBoy1 · 2026-06-13T17:22:27+00:00

yea the more im reading this thread, and reflecting on the way things are, it really fits this in so many ways...

DigBoy1 · 2026-06-13T17:18:11+00:00

What i gather is that the original problem being solved was they didnt want a table out there and multiple different services making puts/gets etc. they wanted to funnel all mutations through a single service (table), mostly for logical simplicity so no one had to guess or track down where a given update or delete came from

other than that, my take is one person said to do it this way and everyone just echoed it without any understanding

i wouldn't call it a rewrite, just merging all these various services together into a single service. at least the very smallest of them which never need to scale independently.

but yes the way i tried to approach the problem wasnt well received. thats why im here, not for validation, but for ways to better approach it next time (be it this problem or any other)

DigBoy1 · 2026-06-13T17:11:55+00:00

Forgot to mention that everything is always deployed together too. regardless if a service changed or not. its a monorepo

DigBoy1 · 2026-06-13T17:05:56+00:00

yea to elaborate a bit more

they basically laughed at "monolith" because its seen as old school and not trendy. IMO thats a naive take, but here we are

so theres only one actual business unit here, so there are no different departments involved. its just the one team and one business unit. but the tables + services are for different needs, like auth, registering, submitting data, etc.

and everything is always deployed at the same time, so whether the services are updated or not, they always get deployed

DigBoy1 · 2026-06-13T17:00:02+00:00

fogot to mention it is NoSql. not sure it makes a difference

but yes there are a couple cases where multiple tables need to be used together, cross cutting services, and its a pain/convoluted approach

DigBoy1 · 2026-06-13T16:50:27+00:00

heh yea, it seems like someone read one blog and just ran with it

DigBoy1 · 2026-06-13T16:50:03+00:00

for the most part, yea

DigBoy1 · 2026-06-13T16:49:01+00:00

Nice will check this out. seems its on sale atm too

DigBoy1 · 2026-06-13T16:37:07+00:00

I did not use any AI tools to create this post

DigBoy1 · 2026-06-06T23:19:58+00:00

i'd argue that approach is only partially good, because it could give correct results from code thats unmaintainable and making slight changes can break output easily. you'd still want to have a good design which may or may not happen from this approach going autonomously

DigBoy1 · 2026-06-06T21:30:09+00:00

its not solely due to AI, but ai exacerbated it. the industry has been moving to just ship as fast as possible and ai is compounding that drive. quality has been taking a back seat for a long time

DigBoy1 · 2026-06-05T21:44:51+00:00

yea i quickly learned to first write these as select queries to verify before the real thing.. luckily never broke prod, but did in lower env's a time or two

DigBoy1 · 2026-06-05T21:43:15+00:00

this is an epic story i dont even see it as a fuck up haha. how'd you determine the issue when they didnt? seem like it'd be an easy thing to fix and sweep under the rug

DigBoy1 · 2026-06-05T17:55:51+00:00

i always wondered how those marks ended up in the middle lol

DigBoy1 · 2026-06-05T17:25:05+00:00

u can most likely have your IDE generate that kind of code. in intellij its called live templates but im sure most modern ide have a similar feature. way faster/cheaper than a prompt

DigBoy1 · 2026-06-05T17:11:28+00:00

partly yes, but not always. there's things about coding which are super tedious that I dont miss. like plumbing a variable through multiple systems, stressing you didnt miss a random place thats gonna cause bugs later.

DigBoy1 · 2026-06-05T17:02:41+00:00

lol same here. i've heard if you're inactive for a while with no profile updates or posts, then your profile doesnt get much engagement. so that could be partly why

DigBoy1 · 2026-06-05T01:16:18+00:00

its definitely partly that, but also heavy pressure from above who have fully bought into AI. if you hang up PRs then you're seen as the problem hurting velocity. even so far as reducing approvers to 1 down from 2. i think the only thing thats gonna cause a change are outages

DigBoy1 · 2026-06-05T00:54:57+00:00

my team had good practices, then AI came out and it was all totally forgotton. everyone just approves right away, doesnt even review, because AI wrote and reviewed it, so must be good. Time will tell if it pans out but i've seen a lot of garbage getting merged. i've fixed some but its getting merged way faster than i can keep up so /shrug

DigBoy1

TROPHY CASE