AI Staffing Partner

Narender Reddy — Sat, 31 Oct 2026 11:06:25 +0000

Build an AI-powered Resume and Job Description Assistant that analyzes uploaded PDFs, identifies matching and missing skills, compares experience, answers questions, and calculates candidate fit scores using document-based AI retrieval to ensure accurate, evidence-based results through a simple Streamlit interface.

aiStaffingPartner is a Resume and Job Description Assistant.
**Follow these rules:

**1. Answer only the specific question asked by the user.

Use only the provided resume and job-description context.
Give a fit score only when the user specifically asks for:
- a fit score
- resume match percentage
- candidate suitability
- overall fit analysis
For all other questions, provide only the requested information.
Do not invent skills, experience, qualifications or figures.
If the information is unavailable, say: "I don't see this information in the documents."

When a fit score is requested, compute it using this exact rubric.
Do not deviate from these categories or weights, and do not use your own
judgment to invent a different scoring scheme:

Required skills match: 0-40 points (award points proportionally to how many required/must-have skills in the job description are demonstrably present in the resume)
Experience / years relevance: 0-25 points (compare years and relevance of prior roles to the job description)
Education / certifications match: 0-15 points
Domain / industry relevance: 0-10 points
Soft skills / extras (leadership, tools, nice-to-haves): 0-10 points

Show each sub-score explicitly, then sum them for the total (out of 100).
This total is the Fit Score. After the rubric breakdown, provide:

Fit score: X/100
Verdict (Strong Fit / Moderate Fit / Weak Fit)
Matching skills
Missing skills or gaps
Final recommendation

Source Code [https://github.com/nboyapally/aiStaffingPartner]

As developer/user,
1.update generate "open AI API Key" using [https://platform.openai.com/api-keys] and update in ".env" file.

2.Run these commands in VS Code Terminal

python3 -m venv venv
source venv/bin/activate
pip install -U streamlit langchain langchain-openai langchain-community langchain-text-splitters faiss-cpu pypdf
streamlit run app.py

*Visual Studio Code IDE:
*
Visual Studio Code

Execute Commands

Output:

🧅 Onion Architecture Explained Quickly

Narender Reddy — Sat, 18 Apr 2026 07:35:24 +0000

Modern software systems often become hard to maintain as they grow. Business logic gets mixed with UI, databases, and external services, making changes risky and expensive.
This is where Onion Architecture comes in.
It helps developers build applications that are clean, testable, scalable, and easier to maintain.

1) What is Onion Architecture?

Onion Architecture is a software design pattern that organizes your application into layers, like an onion 🧅.
The core business logic stays at the center, while external concerns such as databases, APIs, and UI remain in outer layers.
Core Goal
• Separation of concerns
• Loose coupling
• Dependency inversion
• Clean maintainable code

The core idea:
Keep business rules independent from:
• Database
• UI
• Frameworks
• External APIs
That means your business logic can survive even if technology changes.

2.🧱 Layers of Onion Architecture

Domain Layer (Core)
Application Layer
Infrastructure Layer
Presentation Layer (API/UI) And in pictorial representation as below.

a. 🧠 Domain Model (Core)

This is the heart of the application.
Contains:
• Business entities (e.g., Order, Customer)
• Core business rules
• Domain logic
• Interfaces
• Value Objects
• Business Rules
✔ No dependency on database, UI, or frameworks

b. 📦 Application Services Layer
Acts as a bridge between UI and domain.
Responsibilities:
• Use cases (business workflows)
• Coordinating domain objects
• Calling repositories
Contains

Services
DTOs
Interfaces
Use Cases _________________________________

c. 🌐 Infrastructure Layer
Handles external concerns:
• Database
• APIs
• File systems
Contains:

Entity Framework Core
Repository Implementations
External Services

d. 🖥️ Presentation Layer (UI)
This is what users interact with:
• Web APIs
• MVC Controllers
• Frontend apps
• Contains:

ASP.NET Core Web API
Controllers
UI

3.🔄 Dependency Rule (Golden Rule)

The golden rule of Onion Architecture:
Dependencies always point inward
• Outer layers depend on inner layers
• Inner layers NEVER depend on outer layers

Presentation → Infrastructure → Application → Domain

4.💡 Why Use Onion Architecture?

✅ Benefits

Separation of Concerns • Business logic is clean and independent
Testability • You can test domain logic without database or UI
Flexibility • Easily swap database, UI, or frameworks
Maintainability • Changes in one layer don’t break others ________________________________________

5.🏁 When Should You Use It?

Use Onion Architecture when:
• Building enterprise applications
• Long-term maintainability is important
• Multiple teams work on the system
Avoid it when:
• Small/simple apps
• Quick prototypes

6. Solution Structure:

Sample source code @https://github.com/nrboyapally/OnionArchitecture

7. 🛠️ Common Design Patterns Used

• Dependency Inversion Principle (DIP):The foundation of Onion Architecture. It ensures that high-level modules (the Core) do not depend on low-level modules (Infrastructure) . Instead, both depend on abstractions (interfaces) defined in the inner layers.
• Dependency Injection (DI): Used to provide concrete implementations of interfaces at runtime. In C#, this is typically configured in the Startup.cs or Program.cs file to inject services and repositories into controllers.
Example:
o builder.Services.AddScoped();
o builder.Services.AddScoped();
• Repository Pattern: Creates an abstraction between the domain and the data access layer. It treats data as an in-memory collection, allowing the business logic to remain agnostic of the underlying database technology.
Example:
public interface IProductRepository
{
Task> GetAll();
}
• Service Pattern: Organizes business logic into distinct services. A Service Layer sits between the UI and Repository layers , holding business rules and coordinating tasks.

Domain & Data Patterns

• Domain-Driven Design (DDD) Patterns: Onion Architecture is heavily influenced by DDD. Key patterns include Entities (objects with unique identity), Value Objects (immutable objects without identity), and Domain Services

• Data Transfer Object (DTO): Used to pass data between layers (e.g., from the Application layer to the Presentation layer) without exposing internal domain entities directly to the external world.
• Unit of Work: Often used alongside the Repository pattern to group multiple data operations into a single transaction, ensuring data integrity across different repositories.

Advanced & Behavioural Patterns
• CQRS (Command Query Responsibility Segregation): Frequently combined with Onion Architecture to separate read operations (Queries) from write operations (Commands), often using the Mediator Pattern (via libraries like MediatR).
• Abstract Factory Pattern: Sometimes used to dynamically create instances of repositories or services, further decoupling the application from specific implementations.
• Adapter Pattern: The infrastructure layer essentially acts as a set of adapters that convert external technical details (like SQL or Web APIs) into formats the internal Core can understand.

DEV Community: Narender Reddy