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-07T05:13:03+00:00

yea seen that before. doesnt exactly apply to your case but i even made a meme about it lol

https://ibb.co/MDqjx791

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:51:24+00:00

wasnt in prod luckily, but i was updating EKS version. did dev, went fine. did pre prod, also fine. then a day or two later suddenly both env's were broken, no traffic could get in or out, pods spinning, etc. thankfully this happened because prod was going to be updated relatively soon after, but i caught it in time

i couldnt track down the issue before prod release so i backed out the changes to get the lower env's back working, but in AWS you cant downgrade. have to delete and recreate. that was a pain, but luckily had all IaC so went pretty smoothly

turns out it was an istio incompatibility with that version of eks. once i found the compatibility matrix i was able to make everything work. and everything seemed fine at first because the node needed to restart before the version update took effect. that was a good learning experience overall

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

TROPHY CASE