- ABP Framework version: v9.0.0
- UI Type: Angular
- Database System: EF Core ( PostgreSQL)
- Tiered (for MVC) or Auth Server Separated (for Angular): no
- Exception message and full stack trace: No Exception
- Steps to reproduce the issue: No issue
I need to make SMS (ISmsSender implementation) and other implementations that call API in one of my applications. In which existing project should I create the such concrete classes that require these operations or should I add a new project (Class library) for these operations?
3 Answer(s)
-
0
Where Should You Implement
ISmsSender?When deciding where to place your
ISmsSenderimplementation, it’s essential to consider the role of your application layer and domain layer. In Domain-Driven Design (DDD), we typically categorize domain logic into two types:- Core Domain: Business rules that are fundamental and shared across all applications.
- Application Domain: Application-specific logic that varies based on the type of client (e.g., web, mobile, third-party API).
How This Applies to Your Scenario?
Let’s say you have a Web Application, and in the future, you plan to build:
- A Mobile Application with a simplified user experience that doesn’t require all the same functionalities as the web.
- A Third-Party API where authorization might be handled differently.
In such cases:
- Each of these would have its own Application layer, because their use cases and workflows differ.
- However, if a feature (e.g., sending SMS) is universal across all applications, it should belong to the Core Domain (Domain Layer).
- If the implementation is specific to the Web application (e.g., sending SMS only for web users), then it belongs in the Application layer of that specific project.
Where Should You Implement
ISmsSender?- If SMS sending is a fundamental part of your business logic and will be used across multiple applications, place it in the Domain Layer.
- If SMS sending is specific to your current Web Application, and it may have different implementations for mobile or third-party APIs in the future, place it in the Application Layer of your Web project.
This approach helps reduce code duplication and keeps your architecture scalable and maintainable.
-
0
Hi Berkan, I think you got support from AI while answering my question :) no problem but I find the answer wrong. MySmsSender class is just like EfCoreProductRepository and should not be in domain or application layer. What I asked was can we host it in .HttpApi project, until now we have always progressed by making a separate project. For example BookStore.Integration. I was just wondering if there could be other alternatives before starting my new project. I will continue to host such classes in a new project (module). Thanks anyway.
-
0
Hi Berkan, I think you got support from AI while answering my question :) no problem but I find the answer wrong. MySmsSender class is just like EfCoreProductRepository and should not be in domain or application layer. What I asked was can we host it in .HttpApi project, until now we have always progressed by making a separate project. For example BookStore.Integration. I was just wondering if there could be other alternatives before starting my new project. I will continue to host such classes in a new project (module). Thanks anyway.
Yes, I used AI, but if you give AI your question, you will see that you will get very different answers. I explained to AI my thoughts on the subject and asked him to help me create a text that was more descriptive and clean than my views. In short, the thoughts in my answer are my own thoughts but it was the AI that made the wording more descriptive.
As a result, it is obvious that this decision should be made according to your domain, if you think that designing it as a separate integration package will be better for your project in the future, you can proceed in that way.
