The advice to structure your solution into two different projects, such as Project.Core and Project.Infrastructure, stems from a design pattern that supports separation of concerns and flexibility in software architecture. Here's why this structure is beneficial:
1. Separation of Concerns (SoC):
Project.Core typically contains the business logic and domain entities. This layer is agnostic to external dependencies like databases, web frameworks, or messaging queues. Its focus is purely on the core business rules and domain models.
Project.Infrastructure, on the other hand, contains the implementation of external systems that the core logic interacts with. This could include things like data access, file systems, third-party services, email, logging, or any other external dependencies.
The separation helps in ensuring that the core business logic is not coupled with external technologies, which makes the application more testable, maintainable, and flexible.
2. Testability:
Since Project.Core does not depend on external technologies, it can be easily tested in isolation. You can write unit tests for the core logic without worrying about database connections or API calls.
Project.Infrastructure can be tested independently too, but its purpose is to provide implementations for the abstractions defined in the core, and its main focus is on ensuring those integrations work correctly.
3. Decoupling and Flexibility:
By separating the core logic from infrastructure concerns, the application becomes more adaptable. You could easily swap out the infrastructure layer, for example, change from a SQL database to a NoSQL database, without affecting the core business logic.
It also makes it easier to replace specific implementations, such as using a mock implementation of a service in tests or swapping a logging framework without changing the core logic.
4. Dependency Inversion Principle (DIP):
By using abstractions in the Core (such as interfaces or abstract classes), and implementing them in Infrastructure, you follow the Dependency Inversion Principle, which is a key concept of SOLID design. This ensures that high-level modules (Core) don't depend on low-level modules (Infrastructure) but both depend on abstractions.
5. Reusability:
If you follow this separation of concerns, your Project.Core could potentially be reused across different projects with different infrastructures (such as a different database, messaging service, or web framework). For example, you could create a different infrastructure project for a mobile app or a web API, but the core logic remains the same.
This approach is widely recommended for maintaining clean architecture, especially in larger applications where the complexity grows over time and you need to ensure that different parts of your system evolve independently.
You said:
what about project.worker?
ChatGPT said:
ChatGPT
The Project.Worker in a solution architecture typically refers to a component or project responsible for handling background tasks or asynchronous processing. It often involves long-running processes that can be decoupled from the main user-facing application. The Worker project is often part of an architecture that includes Project.Core, Project.Infrastructure, and potentially other components like Project.Web or Project.API.
Here's why you might have a Project.Worker in your solution, and how it fits into the overall architecture:
1. Asynchronous Processing / Background Jobs:
The Project.Worker project is commonly used for handling long-running tasks such as:
Sending emails
Generating reports
Processing queued jobs
Interacting with external systems in a non-blocking manner
Data synchronization
These tasks are often not part of the main request-response flow of the application but are necessary to complete certain operations or maintain the system.
By offloading such tasks to a worker project, you ensure that the user-facing parts of the system remain fast and responsive without being blocked by these time-consuming operations.
2. Separation of Concerns and Scalability:
The Project.Worker provides a separation of concerns for background processing. You can scale workers independently from the web application or API. If you need more resources to process jobs faster, you can spin up more worker instances without affecting the user-facing components.
This can be especially important in large systems where heavy tasks (like image/video processing, data migration, etc.) may need to be handled asynchronously to avoid bottlenecks in the main application.
3. Integration with Core and Infrastructure:
Project.Worker will typically reference Project.Core to access the business logic and domain models. This allows the worker to use the same domain logic as the main application but does not need to know about external services or technologies.
Project.Infrastructure could also be referenced by Project.Worker if it requires access to external systems, such as queues (e.g., Azure Service Bus, RabbitMQ), file storage, or databases for saving job results or state.
4. Handling External Events or Triggers:
Project.Worker is often used to process events or triggers that may come from external systems or queues. For example:
A message in a queue (e.g., RabbitMQ, Azure Queue Storage) could trigger a worker to start processing.
A cron job or scheduled task might trigger the worker to perform periodic maintenance (e.g., clearing expired sessions, updating cache).
5. Worker Frameworks:
In many .NET solutions, workers are often implemented using frameworks like Hangfire, Quartz.NET, or Azure Functions. These frameworks provide an easy way to manage background jobs, scheduled tasks, and retries, and they integrate with your solution’s Core and Infrastructure layers.
For example, in a Project.Worker using Hangfire, you might have methods like BackgroundJob.Enqueue() to schedule a task. These tasks might interact with Project.Core to perform business logic, but they can also be decoupled from direct user interaction.
6. Fault Tolerance & Retries:
Workers can be designed to handle job retries, timeouts, and failures. For example, if a job depends on an external service that temporarily fails, you can retry the task later, potentially with exponential backoff or using a dead-letter queue for problematic tasks.
This ensures that background jobs are resilient and won't cause significant issues if an external dependency fails temporarily.
7. Scaling the Worker Layer:
Workers are often scaled horizontally. If your application requires high-throughput background jobs, you can scale up the number of worker instances (e.g., using multiple worker services in the cloud or a containerized environment) without touching the rest of the system.
This allows for flexible resource allocation and helps ensure that background tasks can be processed at scale without affecting the main application.
Example Project Structure:
Project.Core: Contains business logic, domain models, and abstractions.
Project.Infrastructure: Contains external integrations (database, messaging queues, email, etc.).
Project.Web: The user-facing component (e.g., a web app or API).
Project.Worker: A background worker responsible for processing long-running, asynchronous tasks.
Why Have a Separate Project.Worker?
Encapsulation of background logic: Having a separate project for background work makes it easier to focus on and maintain the logic for those processes.
Independent scalability: Workers can scale independently from the main web app. If you need to process large batches of data or messages, you can scale out workers to handle that load without affecting the user-facing application.
Cleaner separation of concerns: It keeps the user-facing application free from concerns about job scheduling, retry mechanisms, and background job monitoring.
In summary, the Project.Worker project serves a distinct purpose from the Core and Infrastructure layers, focusing on background task processing. It works well with a clean architecture approach, keeping the system modular, testable, and scalable.
You said:
where can I read more about this?
ChatGPT said:
ChatGPT
If you're interested in reading more about this architectural approach, including the separation of concerns, background workers, and clean architecture principles, here are some recommended resources:
1. Books:
Clean Architecture: A Craftsman's Guide to Software Structure and Design by Robert C. Martin
This book provides a deep dive into the clean architecture approach, emphasizing the separation of concerns, dependencies, and modularity in software design. It’s a great foundation for understanding why you might separate the core, infrastructure, and worker layers in a solution.
Clean Architecture on Amazon
Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans
This book introduces the concept of Domain-Driven Design (DDD), which influences the idea of separating business logic (core) from infrastructure concerns. It’s especially useful if you’re dealing with complex business domains and want to structure your application accordingly.
Domain-Driven Design on Amazon
Microservices Patterns: With Examples in Java by Chris Richardson
Although this book is written with Java in mind, its patterns for microservices architecture—such as decoupling different layers (core, infrastructure, worker)—apply to any technology stack, including .NET.
Microservices Patterns on Amazon
2. Online Resources:
Ardalis' Blog
Steve Smith (Ardalis) regularly publishes blog posts on clean architecture, dependency injection, and related topics. His articles are a great resource for understanding the reasoning behind using patterns like the ones you mentioned (Core, Infrastructure, Worker).
Ardalis Blog
Clean Architecture Articles on Medium
Many software architects and developers write on Medium about the principles behind clean architecture. You can find articles that explain the importance of separating concerns, using background workers, and how to structure your solution.
Clean Architecture Articles on Medium
Microsoft Docs on .NET Architecture
Microsoft provides extensive documentation on .NET architecture and best practices, which includes separation of concerns, service design, and background job processing.
Microsoft .NET Architecture Documentation
Stack Overflow Discussions
For specific questions or community discussions, Stack Overflow is a great place to explore how other developers have approached similar problems, including the use of background workers, clean architecture, and structuring .NET projects.
Stack Overflow - Clean Architecture
3. Videos & Tutorials:
Clean Architecture - YouTube (by Uncle Bob)
Robert C. Martin (Uncle Bob) has several talks and tutorials on clean architecture available on YouTube. His videos explain the principles of keeping business logic separate from infrastructure concerns, which is relevant to your question.
Clean Architecture YouTube Playlist
Pluralsight Courses by Steve Smith
Steve Smith has several Pluralsight courses that cover topics like clean architecture, dependency injection, and background job processing in .NET. These courses are practical and well-structured for developers at different levels.
Steve Smith on Pluralsight
4. Frameworks for Background Jobs:
Hangfire Documentation
Hangfire is a popular library for background job processing in .NET. Its documentation covers how to implement background jobs, retries, and scheduling, which ties into the idea of creating a Project.Worker.
Hangfire Documentation
Azure Functions Documentation
If you're considering using Azure Functions for background tasks, Microsoft provides documentation on how to implement serverless functions that can act as workers to process tasks asynchronously.
Azure Functions Documentation
By diving into these resources, you’ll be able to get a deeper understanding of the concepts behind clean architecture, separation of concerns, and worker design patterns in .NET applications.
You said:
Project.Core typically contains the business logic and domain entities. This layer is agnostic to external dependencies like databases, web frameworks, or messaging queues. Its focus is purely on the core business rules and domain models.
Project.Infrastructure, on the other hand, contains the implementation of external systems that the core logic interacts with. This could include things like data access, file systems, third-party services, email, logging, or any other external dependencies.
give small code example pelase
ChatGPT said:
ChatGPT
Here's a simple code example demonstrating how you might structure the Project.Core and Project.Infrastructure layers in a clean architecture:
1. Project.Core (Business Logic and Domain Entities)
This layer contains domain entities and interfaces for business logic, abstracting away any external dependencies.
Entities:
csharp
Copy code
// Project.Core/Entities/Order.cs
namespace Project.Core.Entities
{
public class Order
{
public int Id { get; set; }
public string CustomerName { get; set; }
public decimal TotalAmount { get; set; }
}
}
Interfaces (e.g., for sending email):
csharp
Copy code
// Project.Core/Interfaces/IEmailService.cs
namespace Project.Core.Interfaces
{
public interface IEmailService
{
void SendEmail(string to, string subject, string body);
}
}
Business Logic (Service Layer):
csharp
Copy code
// Project.Core/Services/OrderService.cs
using Project.Core.Entities;
using Project.Core.Interfaces;
namespace Project.Core.Services
{
public class OrderService
{
private readonly IEmailService _emailService;
public OrderService(IEmailService emailService)
{
_emailService = emailService;
}
public void ProcessOrder(Order order)
{
// Business logic for processing an order
// E.g., calculate discounts, update inventory, etc.
// For simplicity, we'll just send an email.
_emailService.SendEmail(order.CustomerName, "Order Processed", $"Your order total is {order.TotalAmount}");
}
}
}
2. Project.Infrastructure (External Dependencies)
This layer contains concrete implementations of the interfaces defined in Project.Core. It deals with external systems like databases, email servers, etc.
Email Service Implementation:
csharp
Copy code
// Project.Infrastructure/Services/EmailService.cs
using Project.Core.Interfaces;
namespace Project.Infrastructure.Services
{
public class EmailService : IEmailService
{
public void SendEmail(string to, string subject, string body)
{
// Here, you might call a real email service, like SMTP or SendGrid.
// For now, we'll just simulate sending an email.
System.Console.WriteLine($"Email sent to {to} with subject '{subject}' and body: {body}");
}
}
}
Data Access (Example Repository for Orders):
csharp
Copy code
// Project.Infrastructure/Data/OrderRepository.cs
using Project.Core.Entities;
using Project.Core.Interfaces;
using System.Collections.Generic;
namespace Project.Infrastructure.Data
{
public class OrderRepository : IOrderRepository
{
private List<Order> _orders = new List<Order>();
public void AddOrder(Order order)
{
// In a real-world scenario, this would save the order to a database.
_orders.Add(order);
System.Console.WriteLine($"Order for {order.CustomerName} added.");
}
public List<Order> GetOrders()
{
return _orders;
}
}
}
3. Dependency Injection in Startup (Setting Up the DI Container)
In a real-world application (e.g., ASP.NET Core), you would wire up these dependencies in the Startup.cs or Program.cs to ensure that the Project.Core and Project.Infrastructure layers can communicate.
csharp
Copy code
// Project.Api/Startup.cs or Program.cs (for ASP.NET Core)
using Microsoft.Extensions.DependencyInjection;
using Project.Core.Interfaces;
using Project.Core.Services;
using Project.Infrastructure.Services;
using Project.Infrastructure.Data;
public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
// Register core services
services.AddTransient<OrderService>();
// Register infrastructure services
services.AddTransient<IEmailService, EmailService>();
services.AddTransient<IOrderRepository, OrderRepository>();
}
}
4. Usage Example (In Application)
Now, you can use the service in your application, for example, within a controller or background worker:
csharp
Copy code
// Project.Api/Controllers/OrderController.cs
using Microsoft.AspNetCore.Mvc;
using Project.Core.Entities;
using Project.Core.Services;
namespace Project.Api.Controllers
{
[Route("api/[controller]")]
[ApiController]
public class OrderController : ControllerBase
{
private readonly OrderService _orderService;
public OrderController(OrderService orderService)
{
_orderService = orderService;
}
[HttpPost]
public IActionResult CreateOrder([FromBody] Order order)
{
_orderService.ProcessOrder(order);
return Ok("Order processed successfully.");
}
}
}
Summary of Layers:
Project.Core:
Contains business logic (OrderService) and domain models/entities (Order).
Defines interfaces (IEmailService, IOrderRepository), but doesn't implement them.
Project.Infrastructure:
Provides concrete implementations of the interfaces from the core layer (EmailService, OrderRepository).
Handles external dependencies (email, data access, etc.).
In this structure:
Project.Core is agnostic to the infrastructure.
Project.Infrastructure implements the necessary functionality, like sending emails or storing orders in a database, while still following the interfaces defined in Project.Core.
This separation ensures that your core business logic is reusable and can be tested independently of the infrastructure.
You said:
so project.Core stores interfaces and project.infratstrucutre implements this?
ChatGPT said:
ChatGPT
Yes, that's correct! The general principle in clean architecture is to separate concerns so that the core business logic (domain) is decoupled from infrastructure concerns. Here’s how it works:
1. Project.Core (Domain Layer)
Contains the interfaces (contracts) that describe what the system should do.
It also contains domain entities (e.g., Order, Customer) that define the structure of data and core business rules.
This layer is agnostic to any external systems, meaning it doesn't know how things like databases, file systems, or email systems work. It only knows what it needs to do.
Key responsibilities:
Defining the domain models (e.g., entities like Order).
Defining the interfaces for services (e.g., IEmailService, IOrderRepository), which are later implemented in the infrastructure layer.
2. Project.Infrastructure (Infrastructure Layer)
Implements the interfaces that are defined in Project.Core.
This layer contains concrete implementations for interacting with external systems, such as databases, email services, file systems, logging, etc.
This layer depends on Project.Core because it needs to implement the contracts defined in the core layer.
Key responsibilities:
Implementing the interfaces defined in Project.Core.
Handling external dependencies like sending emails, reading/writing to databases, interacting with file systems, etc.
Example Breakdown:
Project.Core (Defines Interface)
csharp
Copy code
// Project.Core/Interfaces/IEmailService.cs
namespace Project.Core.Interfaces
{
public interface IEmailService
{
void SendEmail(string to, string subject, string body);
}
}
IEmailService is just an interface that defines what we want to do — send an email — but it doesn’t specify how to send the email.
Project.Infrastructure (Implements Interface)
csharp
Copy code
// Project.Infrastructure/Services/EmailService.cs
using Project.Core.Interfaces;
namespace Project.Infrastructure.Services
{
public class EmailService : IEmailService
{
public void SendEmail(string to, string subject, string body)
{
// Implement the logic to send the email (using SMTP, SendGrid, etc.)
System.Console.WriteLine($"Sending email to {to} with subject '{subject}' and body: {body}");
}
}
}
EmailService implements the IEmailService interface from Project.Core, providing the actual logic for sending an email.
In Summary:
Project.Core defines the "what" (interfaces, business rules).
Project.Infrastructure defines the "how" (concrete implementations for external dependencies).
This separation of concerns allows you to:
Test the business logic in isolation (since it doesn't depend on the infrastructure).
Swap implementations easily (e.g., switching from one email service provider to another, or replacing a database with a different system), without affecting the core business logic.
You said:
who advocates this style? Where can I read more about this?
ChatGPT said:
ChatGPT
The approach of separating concerns into distinct layers such as Core and Infrastructure is a key principle in Clean Architecture, which is advocated by Robert C. Martin (Uncle Bob). Uncle Bob is a well-known software engineer and author who has written extensively about software design principles and clean architecture.
Key Advocates and Concepts:
Robert C. Martin (Uncle Bob): He is the primary advocate for Clean Architecture. His books, talks, and articles provide the foundation for this architectural style. Uncle Bob emphasizes the importance of separating business logic (core domain) from external dependencies (infrastructure). He introduced the concept of dependency inversion, where high-level modules (business logic) are decoupled from low-level modules (infrastructure).
Michael Feathers: Another advocate of clean architecture and working with legacy code. His principles align with the idea of making business logic independent of external systems.
Mark Seemann: A software engineer known for his work in Dependency Injection and Testable Code. His book, "Dependency Injection" and his blog posts, align with the ideas of clean architecture by promoting loose coupling and high cohesion.
Eric Evans: Though not strictly about Clean Architecture, his work in Domain-Driven Design (DDD) emphasizes separating the core domain from the technical infrastructure, which aligns with these ideas.
Where to Read More:
Books:
"Clean Architecture" by Robert C. Martin: This book explains the principles of clean architecture, focusing on how to structure your code to be independent of frameworks, UI, and databases. It advocates creating a well-structured core business logic that is agnostic of infrastructure concerns.
"Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans: While focused on Domain-Driven Design, Evans discusses separating domain logic from infrastructure, similar to the core/infrastructure separation.
"Dependency Injection in .NET" by Mark Seemann: This book discusses how to achieve dependency inversion (a key principle of Clean Architecture) and maintain testable, decoupled code.
Online Resources:
Uncle Bob’s Blog: https://blog.cleancoder.com/ – Uncle Bob writes about clean code, architecture, and software design, emphasizing the importance of separating the business logic from the infrastructure.
Mark Seemann's Blog: https://blog.ploeh.dk/ – Focuses on Dependency Injection and clean architecture practices.
"Clean Architecture" by Uncle Bob – You can find excerpts and articles based on the book online as well.
Videos & Talks:
Uncle Bob's Clean Architecture Videos – Uncle Bob has several talks and interviews available on YouTube where he explains Clean Architecture, the role of dependency injection, and the importance of keeping business logic independent of external dependencies.
"Architecting Software" by Robert C. Martin (YouTube) – A series of talks where Uncle Bob explains various principles of Clean Architecture.
Courses:
Pluralsight: There are various courses on Clean Architecture, Dependency Injection, and Domain-Driven Design available on Pluralsight, which can help you get a deeper understanding of these concepts.
Core Concepts to Look Into:
Clean Architecture: Focuses on separation of concerns, keeping the core business logic (domain) independent of frameworks, UI, and infrastructure.
Dependency Injection: A technique that allows you to inject dependencies (like email services or repositories) into your classes, making them decoupled from specific implementations.
Dependency Inversion Principle: High-level modules should not depend on low-level modules. Both should depend on abstractions (interfaces).
Domain-Driven Design (DDD): Focuses on structuring your code around the business domain, which aligns with separating business logic from infrastructure.
By reading these resources, you'll get a better understanding of why Project.Core and Project.Infrastructure are typically separated, and how this structure leads to more maintainable, testable, and flexible software.
You said:
apart from Domain-Driven Design what are ways are there?
ChatGPT said:
ChatGPT
Apart from Domain-Driven Design (DDD), there are other architectural styles and methodologies that promote separation of concerns, modularity, and decoupling of business logic from infrastructure. Below are some of the main approaches:
1. Clean Architecture (Robert C. Martin)
Overview: Clean Architecture is a set of principles designed to create software that is easy to maintain, test, and extend. It suggests organizing code in layers to separate concerns: the core (business logic and domain models) is decoupled from infrastructure (databases, APIs, frameworks).
Key Idea: Like DDD, Clean Architecture advocates separating your business logic from external dependencies, but it's more focused on making sure your business logic remains isolated from anything that could change (like frameworks and databases). It promotes the Dependency Inversion Principle (DIP), where dependencies are inverted so that core logic does not depend on external systems.
Structure: Core logic is surrounded by layers that implement infrastructure concerns. The layers depend on abstractions, not concrete implementations.
Where it differs from DDD: While DDD focuses on designing the domain model around business processes, Clean Architecture focuses more on separation of concerns and how dependencies should be managed and structured across layers.
Read more:
"Clean Architecture" by Robert C. Martin
Uncle Bob’s blog
2. Hexagonal Architecture (Ports and Adapters)
Overview: Hexagonal Architecture, also known as Ports and Adapters, emphasizes separating the application into a core (business logic) and the external systems (infrastructure). It uses ports (interfaces) to define how the core interacts with external systems and adapters to implement these interfaces.
Key Idea: The core logic (business rules) is independent of any external systems. Instead of directly coupling the core to databases, UI frameworks, or external services, you define ports that represent the external interactions. The actual implementation of these ports is provided by adapters.
Structure: The central hexagon represents the core domain (business logic), and external systems (like databases, UI, APIs) interact with the core through well-defined ports. Adapters translate between the core and external systems.
Where it differs from Clean Architecture: Hexagonal Architecture focuses on the interface-driven design, while Clean Architecture emphasizes layering and dependency management between the core and infrastructure.
Read more:
"Hexagonal Architecture" by Alistair Cockburn (who coined the term)
Hexagonal Architecture
3. Onion Architecture
Overview: Onion Architecture is similar to Clean Architecture and Hexagonal Architecture in its goal to separate the core domain from the infrastructure. It visualizes the application as layers, where the core logic (domain) resides in the inner layers and the infrastructure resides in the outer layers.
Key Idea: The architecture's core contains the domain model, business logic, and interfaces. The inner layers should not depend on outer layers, but outer layers can depend on inner layers.
Structure: The innermost layer represents the domain entities (business logic), surrounded by layers of application services, repositories, and infrastructure components.
Where it differs from Clean Architecture: Onion Architecture typically emphasizes more about how different layers can be accessed, ensuring that the core is always independent of any framework or technology.
Read more:
"Onion Architecture" by Jeffrey Palermo
Onion Architecture
4. Service-Oriented Architecture (SOA)
Overview: SOA is a design paradigm where the software is broken down into independent services that communicate with each other over a network. Each service represents a distinct business capability and is typically self-contained, meaning it encapsulates its own business logic and data access.
Key Idea: Services are decoupled from one another and communicate using well-defined APIs (often HTTP or messaging protocols like SOAP or REST). SOA emphasizes loose coupling between services, allowing them to evolve independently.
Structure: Each service has its own domain model and interacts with other services via messages or requests. Services are reusable, scalable, and replaceable.
Where it differs from DDD: SOA focuses more on the decomposition of the system into services that communicate over the network, while DDD is more about designing a rich domain model that reflects the business needs.
Read more:
"Enterprise Integration Patterns" by Gregor Hohpe and Bobby Woolf
SOA Fundamentals
5. Microservices Architecture
Overview: Microservices is a variant of SOA but with a focus on building applications as a suite of small, independent services that can be developed, deployed, and scaled independently.
Key Idea: Each service is responsible for a specific business function, and they communicate through lightweight protocols (like HTTP/REST, messaging queues, etc.). Each service is self-contained, with its own business logic, database, and infrastructure components.
Structure: Services are loosely coupled and focus on a single domain, often mapping to business capabilities. Communication between services is handled via APIs or messaging systems.
Where it differs from DDD: While DDD focuses on building rich domain models and understanding business problems, microservices focuses on distributed system architectures with independently deployable services.
Read more:
"Building Microservices" by Sam Newman
Microservices.io
6. Layered (N-Tier) Architecture
Overview: The Layered Architecture (often referred to as N-Tier) separates the application into layers, each of which has a specific responsibility (e.g., presentation, business logic, data access). Each layer interacts with the layer directly below it.
Key Idea: The most common layers include:
Presentation layer: The user interface (UI) layer.
Business logic layer: Where the core logic of the application resides.
Data access layer: Manages interaction with data storage (e.g., database).
Structure: The layers are stacked on top of each other, and each layer only communicates with the layer directly below it. The business logic layer would typically be independent of the data access layer.
Where it differs from DDD: Layered architecture is often less focused on domain complexity and more on technical separation of concerns between UI, business logic, and data access.
Read more:
Layered Architecture Pattern
Conclusion:
While Domain-Driven Design (DDD) is one of the most comprehensive methodologies to structure complex systems around business domains, there are several other architectural styles such as Clean Architecture, Hexagonal Architecture, Onion Architecture, Microservices, and Service-Oriented Architecture (SOA) that also focus on the separation of concerns and the decoupling of business logic from external systems. Each of these has different focuses, such as modularity, scalability, and loose coupling, but they all share the goal of creating maintainable, flexible, and testable systems.
