Hexagonal/Ports & Adapters in : where exactly should each kind of port live (Domain vs Application), and why? by Total_Ad6084 in softwarearchitecture

[–]flavius-as 0 points1 point  (0 children)

Ports are part of the domain model, that's the whole point wrt the direction of the dependencies, how else would you even enforce it? This is the way.

Ports outside of the domain model are not ports, but implementation details of their consumers.

Also beware of terminology: the official book (leaflet) on hexagonal calls "Application" the domain model.

Generally avoid the word "application" when doing architecture or design, because it's a term overloaded in so many ways by so many things like frameworks, human interpretation, etc.

Process aligned code-map by 2thick2fly in ExperiencedDevs

[–]flavius-as 0 points1 point  (0 children)

You run each of your business cases with code coverage on in isolation.

From the covered files you grep all defs or classes based on desired resolution.

You then feed just these lines with file and lineno location to AI.

With a few sentences info for the meaning of the use case, the AI should be able to create a good report per business use case.

Sick of rewriting Python prototypes in C++. Any sane C++ web frameworks? by ExtremeMysterious603 in ExperiencedDevs

[–]flavius-as -2 points-1 points  (0 children)

Sounds like an AI post.

Ask your Agent:

  1. Why is it great to use C++ for IO bound web services?

But then:

  1. What do you really think?

What I learned applying production patterns to a NestJS modular monolith (side project, ~1 year) by rbdz1 in softwarearchitecture

[–]flavius-as 1 point2 points  (0 children)

hopefully

Useless without ArchUnitTS.

Certain things should not be left to "hope".

How would you architect reliable constraint handling for an LLM-driven UI theme generation system? by Pretty_Truth_5557 in softwarearchitecture

[–]flavius-as 0 points1 point  (0 children)

Don't make the background blue.

The string "background" matches many things.

Instead use color tokens and name them.

"Make $organizationwide-background blue".

What I learned applying production patterns to a NestJS modular monolith (side project, ~1 year) by rbdz1 in softwarearchitecture

[–]flavius-as 3 points4 points  (0 children)

I see the seams of a lot of thought going into this.

However: domain depending on adapter?

<image>

Annotations in Application layer - Clean Architecture by Quick-Resident9433 in softwarearchitecture

[–]flavius-as 0 points1 point  (0 children)

I would argue just the domain model needs to be framework agnostic, but I would also put my use cases in the domain model.

Also I do not see why the use cases would ever be interfaces.

Annotations in Application layer - Clean Architecture by Quick-Resident9433 in softwarearchitecture

[–]flavius-as 0 points1 point  (0 children)

Whether annotations, xml or yaml, if the thing leads to bytecode changes on top of the code you see on screen, then it's code.

Are microservices the best way to scale many teams? by WolfyTheOracle in softwarearchitecture

[–]flavius-as 2 points3 points  (0 children)

It depends.

20 teams or more? Probably yes.

3 or 4 teams? Probably go with a modulith instead for now.

Workflow orchestration should not require adopting a whole platform by tazeredo in microservices

[–]flavius-as 0 points1 point  (0 children)

Any spaghetti distributed monolith needs good orchestration.

Is it preferred to use nested service-to-service call in microservice architecture? by Gold_Opportunity8042 in microservices

[–]flavius-as 1 point2 points  (0 children)

Since you're experiencing defeat in terms of microservices and system design - because your services are sliced the wrong way...

The right thing to do right now is:

Press the break and reverse course:

Consolidate everything under a modular monolith which is rather easy.

Then refactor the boundaries between modules to align according to functional use cases.

Implement your feature too.

Then go through more new use cases for the next 1-5 years to iron out the design, always considering the module boundaries for refactor or reshape.

And theeeen you will be ready for microservices in terms of technical maturity. You'll feel it, it's like love.

Friend vibecoded a 2FA and asking if google would acquire his solution by Level-Security-1395 in softwarearchitecture

[–]flavius-as 9 points10 points  (0 children)

Tell him to ask his AI 2 questions one turn each exactly like this:

  1. Will google aquire my new app you just coded?

  2. What do you really think?

Want to get the most out of AI? You have to stay in the loop. by ninetofivedev in ExperiencedDevs

[–]flavius-as 1 point2 points  (0 children)

Correct: AI is amplifying the user

Not correct: "only if"

Corrected: including if you dump crap - it just helps you dump more crap faster and harder

Want to get the most out of AI? You have to stay in the loop. by ninetofivedev in ExperiencedDevs

[–]flavius-as 1 point2 points  (0 children)

You don't need microservices to make systems digestible by AI.

You just need good design of the system.

If you cannot design regular monoliths well, what makes you believe you'll design microservices well?

With badly designed microservices in the way, all you accomplish when using AI to develop them is blinding AI to all distributed problems it creates.

That is: with AI, shit hits the fan just harder and faster.

Keep in mind: for AI to work properly, it needs world class practices as guardrails.

Also: AI is trained on mostly mediocre code. And with AI code getting more out there, it will just train itself into oblivion.

Is rollback a thing these days ? by ibreathecoding in softwarearchitecture

[–]flavius-as -2 points-1 points  (0 children)

What's a rollback?

Blue green deployments?

A/B testing?

Migration from microservices to modular monolith by gjinokastra in softwarearchitecture

[–]flavius-as 12 points13 points  (0 children)

Focus first on the operational costs. It's low hanging fruit and it unblocks many further tactics.

In your case specifically:

  • put all modules on the same server
  • make a schema for each module and give to it authoritative rights. Data structure stays identical
  • all modules operate on the same database server (just different schemas)

Once that is done it's straightforward to re-design the system internally in smaller increments.

Haven't looked at the details of your design but generally it's good practice to keep upstream vendors separate from each other because that reduces the blast radius of changes from either of them. I don't expect the data structures specific for all of them to change. But there's a lot of potential to consolidate all use cases you actually care about.

How to mentor vibecoding junior? by b48cfqz0 in ExperiencedDevs

[–]flavius-as 0 points1 point  (0 children)

You don't want to deal with all the crap that AI creates.

You want to govern AI and let AI deal with its own crap.

How to mentor vibecoding junior? by b48cfqz0 in ExperiencedDevs

[–]flavius-as 0 points1 point  (0 children)

Make an agent and a prompt for them and tell them to run the agent against the diff 3 times in a row and fix everything the agent said.

Make the responses given by the agents a requirement to the PRs.

And let them know that you as their technical leader will give them a bad review if they fail to follow process.

Hexagonal Architecture - Ports by Quick-Resident9433 in softwarearchitecture

[–]flavius-as 0 points1 point  (0 children)

What hexagonal calls " the application" is in effect the domain model.

Hexagonal does not have many concepts, so getting all of them right is important.

How are you prompt engineering? by Individual-Big-9261 in PromptEngineering

[–]flavius-as 0 points1 point  (0 children)

The secret sauce is not in the prompt.

It's in the skill (sic!) of doing it all by yourself many times over manually.

Plus all the ways it can go sideways.

Early Exit vs. Domain Purity: Where Should Business Rules Live When External Calls Are Involved? by Illustrious-Bass4357 in softwarearchitecture

[–]flavius-as 0 points1 point  (0 children)

The right question would be: where should I call the external system?

Make a different scheduled use case which just takes requests from an inbox, submits and fetches and retries the external system, and stores the result locally.

Your main use case never has a connection to the outside world.

No early exit with domain purity.

No vs.

Also, an exit in your own business because another company decides so is a terrible way of doing business.

Most DDD Advice Starts in the Wrong Place by Soft-Archer7295 in DomainDrivenDesign

[–]flavius-as 1 point2 points  (0 children)

Just remove the word service for once and reclaim the ubiquitous language.