₦airaland Forum

https://www.youtube.com/watch?v=Nw4AZs1kLAs?si=lEnH89Ke4yVpsa_b



Microservices Architecture break down applications into loosely coupled, independently deployable services.
ASP.NET Core is a cross-platform, high-performance framework for building modern cloud-based applications. When used to develop microservices, it allows you to create small, independent, and scalable services that can be deployed and maintained separately.

The architecture or the project structures we have the following :

API gateway
Aspire
Eventbus
identity
Services
web/UI (client)



Tools visual studio 2026 or Rider
.NET 10 SDK
SQL server and SQL management studio

Per-function microservices vs Per-feature microservices vs Hybrid approach:

There isn’t a single “best” way to structure microservices per function or per feature—the right choice depends on what you’re optimizing for (speed of delivery, scalability, team structure, or operational complexity). But there are some strong patterns that industry experience consistently converges on.

1. Per-function (technical decomposition)

This means splitting services by technical capability, like:

Auth service
Payment service
Notification service
Logging service

Pros

Clear technical boundaries
Easy to reuse across multiple features
Good for shared infrastructure concerns

Cons

Quickly becomes “distributed monolith”
Features require calls to many services
Harder to understand business flow
Teams get dependency-heavy quickly

👉 This works best for platform/infrastructure services, not full product design.

2. Per-feature (domain / business capability)

This is the dominant modern approach:

“Checkout service”
“Search service”
“User profile service”
“Order management service”

This aligns with Domain-Driven Design (DDD) “bounded contexts”.

Pros

Matches real business logic
Easier to reason about end-to-end features
Better team ownership (one team per domain)
Fewer cross-service calls per feature

Cons

Some duplication (e.g., each service may need auth logic via shared libraries or gateway)
Harder upfront design (you must understand domain well)
Boundaries evolve over time

👉 This is generally considered the “best default” approach today.

3. Hybrid approach (what most mature systems end up with)

Most real systems are not pure either way:

Core domain services (feature-based)
Orders, Payments, Catalog, etc.
Shared platform services (function-based)
Auth, logging, email, analytics, file storage
Edge services
API gateway / BFF (Backend-for-Frontend)

This avoids forcing everything into one decomposition style.

4. What actually matters more than “per function vs per feature”

The real success factors are:

Clear ownership (one team per service)
Loose coupling (no chatty service chains)
High cohesion (one service = one reason to change)
Independent deployability
Strong API contracts
Observability (logs/traces across services)

If those aren’t true, the decomposition style won’t save you.

5. A practical rule of thumb

If you're designing from scratch:

Start with a modular monolith
Define business modules (feature boundaries)
Extract microservices only when:
scaling needs demand it
teams need independent deployment
boundaries are stable and clear

Bottom line
Per-function microservices → good for shared technical infrastructure, not product design
Per-feature microservices → best default for business systems
Hybrid approach → what most scalable real-world systems converge on

MindHacker9009:
Per-function microservices vs Per-feature microservices vs Hybrid approach:

There isn’t a single “best” way to structure microservices per function or per feature—the right choice depends on what you’re optimizing for (speed of delivery, scalability, team structure, or operational complexity). But there are some strong patterns that industry experience consistently converges on.

1. Per-function (technical decomposition)

This means splitting services by technical capability, like:

Auth service
Payment service
Notification service
Logging service

Pros

Clear technical boundaries
Easy to reuse across multiple features
Good for shared infrastructure concerns

Cons

Quickly becomes “distributed monolith”
Features require calls to many services
Harder to understand business flow
Teams get dependency-heavy quickly

👉 This works best for platform/infrastructure services, not full product design.

2. Per-feature (domain / business capability)

This is the dominant modern approach:

“Checkout service”
“Search service”
“User profile service”
“Order management service”

This aligns with Domain-Driven Design (DDD) “bounded contexts”.

Pros

Matches real business logic
Easier to reason about end-to-end features
Better team ownership (one team per domain)
Fewer cross-service calls per feature

Cons

Some duplication (e.g., each service may need auth logic via shared libraries or gateway)
Harder upfront design (you must understand domain well)
Boundaries evolve over time

👉 This is generally considered the “best default” approach today.

3. Hybrid approach (what most mature systems end up with)

Most real systems are not pure either way:

Core domain services (feature-based)
Orders, Payments, Catalog, etc.
Shared platform services (function-based)
Auth, logging, email, analytics, file storage
Edge services
API gateway / BFF (Backend-for-Frontend)

This avoids forcing everything into one decomposition style.

4. What actually matters more than “per function vs per feature”

The real success factors are:

Clear ownership (one team per service)
Loose coupling (no chatty service chains)
High cohesion (one service = one reason to change)
Independent deployability
Strong API contracts
Observability (logs/traces across services)

If those aren’t true, the decomposition style won’t save you.

5. A practical rule of thumb

If you're designing from scratch:

Start with a modular monolith
Define business modules (feature boundaries)
Extract microservices only when:
scaling needs demand it
teams need independent deployment
boundaries are stable and clear

Bottom line
Per-function microservices → good for shared technical infrastructure, not product design
Per-feature microservices → best default for business systems
Hybrid approach → what most scalable real-world systems converge on

I am trying to simplify the concept because many new . NET guys run from it because it is difficult to maintain like monolith which is easier. I don't want to sound scary by quoting concepts they can't understand. If you look at the title you will see it is for beginners not advanced programmers . I didn't even mention Ocelot an open-source API Gateway built specifically for .NET and ASP.NET Core

To deploy your cloud native Microservices create docker images of individual service then upload to AWS or Microsoft Azure with (AKS) via CI/CD local webApi testings are done on postman. If the code is on GitHub you can use automated tools like GitHub actions. It can be hosted on a domain (paid)or subdomain (free sometimes)


if you are using a frontend framework you build it using your package manager to deploy

Alphabyte3:
I am trying to simplify the concept because many new . NET guys run from it because it is difficult to maintain like monolith which is easier. I don't want to sound scary by quoting concepts they can't understand. If you look at the title you will see it is for beginners not advanced programmers . I didn't even mention Ocelot an open-source API Gateway built specifically for .NET and ASP.NET Core

Yeah, I get your point. Apart from being used for large software projects and multiple teams, I feel that for a solo developer who wants to bring other developers into their project, microservices are a good way to distribute tasks so that each developer only has access to their own code.

MindHacker9009:
Yeah, I get your point. Apart from being used for large software projects and multiple teams, I feel that for a solo developer who wants to bring other developers into their project, microservices are a good way to distribute tasks so that each developer only has access to their own code.

I heard .NET 9 no longer supported some apps might want to migrate to .NET 10 but all these can cause real headaches to developers due to discrepancies and errors. November .NET 11 would be released fully with C# 15 .


The Bills of Microservices isn't small because you are cloud services separately and it requires a team

Alphabyte3:
I heard .NET 9 no longer supported some apps might want to migrate to .NET 10 but all these can cause real headaches to developers due to discrepancies and errors. November .NET 11 would be released fully with C# 15 .


The Bills of Microservices isn't small because you are cloud services separately and it requires a team

For solo developers without the budget of big companies for cloud services, they can create their REST API endpoints and host them on shared .NET hosting to save on cost.

Here is a list of breaking changes in .NET 9. If you are not using any of them, then there is nothing to worry about for now.
https://learn.microsoft.com/sk-sk/dotNet/core/compatibility/9.0?utm_source=chatgpt.com