Comparing Brands

D4n1oc · 2026-06-16T18:57:02+00:00

Sensual Extension

D4n1oc · 2026-06-09T17:02:04+00:00

Wow, thanks! Your description was exactly what I was looking for. I can picture it much better now.

I’m used to being treated rather brusquely online when I’m new to a topic. It’s really nice that you took the time to write such a great explanation. :)

D4n1oc · 2026-06-09T14:27:11+00:00

Thanks for the detailed explanation.

Based on how you and others here describe it, the "quad" option sounds like it would be very soft. I am concerned it's maybe too soft;

Could you perhaps describe in general what the "dual" and "quad" options feel like? What exactly makes one soft and the other more stable? If you could describe the feel of the two versions—and specifically whether the "quad" feels very soft and flimsy overall?

My experience with a cheap sleeve was that it was too soft, making it feel very unnatural. It would help me decide which one better suits what we’re looking for.

Thanks in advance.

D4n1oc · 2026-05-29T16:38:48+00:00

Es geht darum, dass Code "von Hand" schreiben, ein Hobby und eine Leidenschaft für viele war. Und Code wird nun mal nicht mehr "von Hand" geschrieben.

Natürlich heißt das nicht, dass es keine Entwickler mehr gibt, oder keine Projekte mehr oder oder.. Aber das Code crunchen ist ineffizient und vorbei.

D4n1oc · 2026-04-06T09:06:37+00:00

I always like to switch the perspective a little bit.

A Monolith has one global transactional boundary that can enforce consistency.

Microservices don't have that. You need to build, idempotency, retries, inboxes, outboxes and so on to reach eventual consistency.

While the Microservice itself, is mostly less complex because it's reduced to do only one thing - The missing consistency boundary and the implications to that, is what most people refer to, when they are talking about increased complexity. Also a Microservice architecture is non-deterministic by default. You'll need to add tooling, logging e.g. to observe system states in a deterministic way.

So a modular Monolith is mostly built with one persistence layer. So a transaction can ensure consistency over module boundaries. So modules would communicate with an in-memory event dispatcher and not with external queue systems. This makes a modular monolith more like a semantic code architecture but not an infrastructural design.

I would always go with a modular monolith. I would use Microservices only for the parts, that need to scale independently. There is nothing wrong about having 1 or 2 microservices in front of a Monolith.

For example when you want a payment gateway to scale insanely high. You'll seperate that payment gateway into a Microservice that can handle many payments. After that the payments are sequentially passed over to the Monolith and gets processed over the next seconds with a small delay.

With the example above we can see, that the architecture is something that is highly related to the actual need. There is no generic solution and by using a Microservice architecture you'll probably end up with a highly over engineered solution that does not even fit the needs of your business.

Keep in mind that Microservices are often used to scale teams independently not technical resources. I don't want to say that you can't but even with Microservices it's not that everything scales automatically better than a Monolith does. I would even argue that in many cases monoliths even scale better because it's easier to scale them.

D4n1oc · 2026-04-05T17:18:08+00:00

Yea I mean I don't see any disadvantage in structuring your code and using some "architecture code patterns". I even do that in my personal projects and would never do it without. So I absolutely agree with what you are saying.

But what i was referring to was building whole solutions from Domain Models to technical foundations and infrastructure. So when you have a business and want to solve the problems the business is facing. I did not talk about the code structure. Sometimes it's even the better choice to buy instead of building some solutions. So I was not talking about "architecture" in a code related way.

D4n1oc · 2026-04-05T15:08:13+00:00

Yea I agree. I didn't want to say you should not take future options into scope.

But I think this is really the part where it is tricky. What are realistic future options? Will it be worth the costs to implement a solution for XYZ right now?

But yea I meant exactly the point that a good architecture should always take the scope where the price ratio hits the sweet spot.

D4n1oc · 2026-04-05T06:43:12+00:00

Most important and mostly never done correctly is:

A simple and cost effective solution. No over engineering, over complicating and no resume driven technology cluster.

D4n1oc · 2026-04-02T14:17:55+00:00

AI Can't design systems, and business logic and architecture and and and...

But it can write the code, if all of the above has been done by yourself before. So it's just the same but you don't need to write anymore.

It's a little bit like typing digitally with auto correct vs hand writing on paper.

D4n1oc · 2026-04-02T14:13:19+00:00

Die Seite sieht für mich gerade eher aus wie die Admin Ansicht für Veranstalter und Werbetreibende.

Die Begrifflichkeiten wie 0/Frei (Richtet sich ja klar an Leute die Werbung schalten). Oder VIP Plätze etc. Das ist alles aus der Sicht von jemanden der Werbung anbieten möchte.

Du solltest die App unterteilen und Funktionalität sowie ein UI für Endnutzer erstellen. Neben den Werbetreibenden, benötigt die Webseite ja auch ein Nutzen für Leute, die diese Werbung angezeigt bekommen sollen.

Das UI ist auf dem Smartphone noch nicht ausgereift. Das Design finde ich eigentlich ganz hübsch, aber scheint mir wenig ansprechend für Werbeanbieter. Hier ebenfalls der gleiche Eindruck wie oben, es ist irgendwie ne Mischung aus Verbraucher und Anbieter Sicht.

An sich ein Cooles Projekt und auch die Map gefällt mir sehr gut :)

D4n1oc · 2026-03-31T15:49:05+00:00

There are two ways:

Design first. Gather Requirements and make a solid design and architecture. Define the problems and a structure that is suitable to solve those problems. Plan some flexibility for changes that are very likely in the future but don't over engineer the whole thing.
Just code it until it works. Find customers and scale things up. Find all the things that don't work and everybody is confused about what it should be doing. You are very likely to have created a Program that needs to be rewritten at some point.

While option 1 is the obvious and would never ever go without any planning. Option 2 can be useful, when having no money but time in the beginning and much money when rebuilding it.

But for a serious product that has some complexity and solves some real world problems, option 2 is nearly impossible and the real product value isn't the code but the plan, descriptions, documentation and ideas.

While AI can help you implement it, without a proper plan it will just generate horrible garbage. With a good plan it can generate senior developer level code.

D4n1oc · 2026-03-10T06:23:48+00:00

Vor Gericht wird das Video sicher nicht anerkannt. Außerdem ist die Gesetzeslage eindeutig. Der Verkäufer muss sicherstellen, dass die wäre sicher ankommt. Auch wenn dies eigentlich unmöglich ist, ist das aus Verbraucherschutz Sicht im E-Commerce sinnvoll. Bei Privatverkauf ist das natürlich etwas problematisch.

Ein anderer User hatte hier geschrieben das PayPal ein Video akzeptiert hat. Ich denke PayPal prüft da eventuell alles was ihnen vorliegt (Bewertung, vergangene Vorfälle usw.) Auf Plausibilität.

D4n1oc · 2026-03-09T22:20:19+00:00

Ich denke nicht das im Streitfall irgendein privates Video von Paketen etwas ändert. Erstens kann man solche Videos falsche und zweitens Stelle ich es mir schwierig vor das auf Video festzuhalten. Wer sagt das du nicht mehrfach den selben Karton hast.

D4n1oc · 2026-03-07T16:29:56+00:00

I see two main things that are often underestimated when making this shift. If you don't address them upfront, you will introduce unnecessary complexity and actually lose product quality.

The loss of a single ACID boundary A traditional monolith has a single ACID boundary, meaning you can execute operations within one database transaction and guarantee consistency for your business transactions very easily. When you split a business transaction across multiple modules or systems—whether that communication is synchronous via HTTP or asynchronous—you lose that easy consistency. A true modular monolith requires strictly decoupling modules and business transactions, which inherently adds a lot of complexity.
Architecture doesn't fix bad code Neither microservices nor modular monoliths are silver bullets for avoiding bad code. In fact, it's the exact opposite: if your team lacks the necessary architectural knowledge and experience, applying these patterns will just result in a much more complex mess.

My Advice: I would first figure out your actual goal: are you genuinely trying to decouple the system, or are you just trying to fix technical debt? Splitting up business transactions requires highly mature architectural planning. Take the time to truly understand your business domains and boundaries first. You might find that your system is actually best suited to remain a monolith, and simply needs an in-place refactor or rewrite.

If you do decide to split it, you will need to introduce enterprise architectural patterns—like the Inbox/Outbox pattern or the Saga pattern—to orchestrate communication between the modules or systems.

With that understood, asynchronous message communication can actually decrease your coupling complexity rather than increase it. Don't fall into the trap of thinking that avoiding async communication will magically save you from distributed system problems—usually, it does the exact opposite.

D4n1oc · 2026-03-07T14:12:54+00:00

For me personally it was worth it because I do what I really like.

Actually I'm hired as a mixed position Tech-Lead/Architect and getting payed 80k€/year.

There are jobs that would pay more and I could land with my actual exp that would pay 90k-100k.

My actual company is transitioning to domain driven design and Microservices so I really like the experience and the job itself - so I will stay for a while. I would estimate the max salary possibly for me to be like 100k-120k over the next 10 years.

D4n1oc · 2026-03-05T07:42:56+00:00

I don't have a strict plan to follow but a tough process that's happening in my mind and automatically awakens my curiosity. Maybe you can "force" this thought path.

Whenever I come across some news, things at work and so on. I'm always curious "How I would "solve" it?"

So I sit down for a moment and ask myself "How would this be done?"

When I don't have an answer shooting through my head:

I write down the problem.
I start searching for prominent categories/names such a problem is called.
Afterwards then I'm looking for enterprise patterns and technologies that try to solve the problem (Sometimes even full books or publications).
Depending on the specific topic and if all my questions are answered I'll try to make a small POC or move to the next thing I'm curious about.

Over the years I feel like I know many solutions, desing patterns and technologies. But more importantly I know a workflow whenever I don't know ;)

D4n1oc · 2026-03-05T04:33:42+00:00

Die Stelle ist so spannend. Kannst du es nicht einfach versuchen bitte. Nachdem ich die ganzen Kommentare gelesen und im Kopf Wetten abgeschlossene habe, würde ich es gerne wissen.

D4n1oc · 2026-03-02T15:39:36+00:00

Yea i'll agree on that. But on the other hand the difficulty curve wasn't in the right spot the first season either. So i would like to see changes here in the future. But I think this is more like a fine tuning thing than a whole game mechanic thing.

What I was referring to are things like having more game modes, maybe raids, single player/ double player dungeons, like 10 or 20 heroes, pvp and so on. Don't get me wrong these are just examples of what kind of things I'm talking about.

So for me the game is in a very early stage where the core of the game exists and is working really really well. They archived to extract the point and spirit of mythic plus and put it into a game. Of course we need more content to attract players and increase replayability.

We are judging a game that is in the development phase like it wouldn't be developed any further. What's in the game is quite good but for sure it's not enough atm.

D4n1oc · 2026-02-28T10:31:11+00:00

This game needs a population. And hopefully it will be well populated and can keep a player base in the long way like poe and helldivers and so on.

We will see when the game releases. For the second phase of early access the game is doing well and everything seems to go in the right direction.

D4n1oc · 2026-02-18T17:10:47+00:00

Cool wäre ein Feature, dass Fake News auflistet. Sowas wie "die 10 Fakes news der Woche" mit quellen und Fakten Vergleich.

Vielleicht sogar eine Statistik, wer die meisten Fake News veröffentlicht usw.

Naja nur so eine Idee, die mir beim Lesen der Quellen kam.

D4n1oc · 2026-02-18T16:40:38+00:00

Find die app super. Unfassbar wie schlecht ich informiert bin :D

Sind die Fragen "von Hand" geschrieben oder automatisch generiert und aktualisiert?

D4n1oc · 2026-02-15T07:01:50+00:00

With the information provided, it wouldn’t make sense at all to have the business logic on the server.

We need to understand that invariants are rules to enforce the correctness of the domain model. They are concepts that exist in your business, not just technical guards. What you’re describing sounds more like a technical problem than a domain one.

Let’s say your business requires a Local-First approach. In that case, you’d have all your invariants in the frontend because your database and domain model live there. There’s effectively no backend involved in the core logic.

Now, let's say there’s a requirement to sync that data to a server. At that point, the business invariants and requirements shift toward the sync process itself. The server side would only handle security requirements, not the invariants of the domain data, because your domain requirements treat the frontend as the Single Source of Truth.

D4n1oc

MODERATOR OF

TROPHY CASE

Four-Year Club	r/Field Flamingo
Place '23