I am using Repository Pattern, Service pattern, unit of work pattern. I am little bit confused that where should I place my business logic. whether It should be in the service or in the repository class.
Usually business logic is added to services and repository is used to access the data.
Related
I have been assigned to think of a layered microservices architecture for Azure Service Fabric. But my experience mostly been on monolithic architectures I can't come up with a specific solution.
What I have thought as of now is like...
Data Layer - This is where all the Code First entities resides along with DBContext.
Business Layer - This is where all the Service Managers would be performing and enforcing the Business Logic i.e. UserManager (IUserManager), OrderManager (IOrderManager), InvoiceManager (IInvoiceManager) etc.
WebAPI (Self Hoted Inside Service Fabric) - Although this WebAPI is inside Service Fabric but does nothing except to receive the request and call respectic Services under Service Fabric. WebAPI Layer would also do any Authentication and Authorization (ASP.NET Identity) before passing on the call to other services.
Service Fabric Services - UserService, OrderService, InvoiceService. These services are invoked from WebAPI Layer and DI the Business Layer (IUserManager, IOrderManager, IInvoiceManager) to perform it's operation.
Do you think this is okay to proceed with?
One theoretical issue though, while reading up for several microservices architecture resources, I found that, all of them suggests to have Business Logic inside the service so that the specific service can be scaled independently. So I believe, I'm violating the basic aspect of microservices.
I'm doing this because, the customer requirement is to use this Business Layer across several projects, such as Batch Jobs (Azure Web Jobs), Backend Dashboard for Internal Employees (ASP.NET MVC) etc. So If I don't keep the Business Layer same, I have to write the same Business Logic again for Web Jobs and Backend Dashboard which I feel is not a good idea. As a simple change in Business Logic would require change in code at several places then.
One more concern is, in that case, I have to go with Service to Service communication for ACID transactions. Such as, while creating an Order, a Order and Invoice both must be created. So in that case, I thought of using Event Driven programming i.e. Order Service will emit an event which the Invoice Service can subscribe to, to create Invoice on creation of Order. But the complications are if the Invoice Service fails to create invoice, it can either keep trying do that infinitely (which is a bad idea I think), or emit another event to Order Service to subscribe and roll back the order. There can be lots of confusion with this.
Also, I must mention that, we are using a Single Database as of now.
So my questions are...
What issue do you see with my approach? Is it okay?
If not, please suggest me a better approach. You can guide me to some resources for implementation details or conceptual details too.
NOTE : The requirement of client is, they can scale specific module in need. Such as, UserService might not be used much as there won't be many signups daily or change in User Profile, but OrderService can be scaled along as there can be lots of Orders coming in daily.
I'll be glad to learn. As this is my first chance of getting my hands on designing a microservices architecture.
First of all, why does the customer want to use Service Fabric and a microservices archtecture when it at the same time sounds like there are other parts of the solution (webjobs etc) that will not be a part of thar architecture but rather live in it's own ecosystem (yet share logic)? I think it would be good for you to first understand the underlying requirements that should guide the architecture. What is most imortant?
Scalability? Flexibility?
Development and deployment? Maintinability?
Modularity in ability to compose new solutions based on autonomous microservices?
The list could go on. Until you figure this out there is really no point in designing further as you don't know what you are designing for...
As for sharing business logic with webjobs, there is nothing preventing you from sharing code packages containing the same BL, it doesn't have to be a shared service and it doesn't mean that it has to be packaged the same way in relation to its interface or persistance. Another thing to consider is, why do you wan't to run webjobs when you can build similar functionality in SF services?
Is it possible to create liferay service builder without any configuring any database tables in service.xml file.
Actually purpose here is to create a service layer using liferay service builder. And there is no database interaction directly in this service layer.
Yes, and it's quite simple. While you still need an entity (which provides the name for your service) you can leave this entity definition empty.
This will create the service (local or remote, as configured in the entity) but no model, no persistence and no database table.
One of the situations where this comes in really handy is when you want to add another method to an existing service (which you can't) - you just create a new service with your custom methods and delegate to the original service.
I agree with #Olaf Kock answare in which say that it is possible have an empty model with service builder. Furthermore have an empty entity you can benefit of have the same transactional context of your portal and benefit of cluster managing and benefit of a complete integration with liferay portal.
If you have the same transactional enviroment of the portal you can image of create a service that agregate native liferay service and you get the assurance that the transactional context is the same of the portal.
I hop that this reflection can add value.
Its highly recommended that If you're creating Service.xml then at least one entity should be there. Otherwise no need to add that configuration.
Able to create service builder without real entities.
As provided in the link it is possible to create service builder without entities.
Also discussed more in detail in this forum
Hope it helps some one. Thanks
Which of the following util is suitable for creating an organization using Liferay API.
i) OrganizationUtil
ii) OrganizationServiceUtil
iii) OrganizationLocalServiceUtil
Basically, I want to know the difference between these three.
i) OrganizationUtil: com.liferay.portal.service.persistence.OrganizationUtil
The classes from the persistence layer directly talk to the Database and hence are good to be used from the service layer and also if you care about transaction.
Following are the words from the documentation:
The persistence utility for the organization service. This utility wraps OrganizationPersistenceImpl and provides direct access to the database for CRUD operations. This utility should only be used by the service layer, as it must operate within a transaction. Never access this utility in a JSP, controller, model, or other front-end class.
ii) OrganizationServiceUtil: com.liferay.portal.service.OrganizationServiceUtil
It can be called from any layer as such. This class also does permission checks (based on Permissions given in Liferay) which may be useful in some cases. This can also be used through web-service.
Well lets see what liferay's documentation has to say:
The utility for the organization remote service. This utility wraps com.liferay.portal.service.impl.OrganizationServiceImpl and is the primary access point for service operations in application layer code running on a remote server.
This is a remote service. Methods of this service are expected to have security checks based on the propagated JAAS credentials because this service can be accessed remotely.
iii) OrganizationLocalServiceUtil: com.liferay.portal.service.OrganizationLocalServiceUtil
This can also be used if you don't want any permission checks. The OrganizationServiceUtil ultimately makes a call to the localService layer.
Liferay's Documentation:
The utility for the organization local service. This utility wraps com.liferay.portal.service.impl.OrganizationLocalServiceImpl and is the primary access point for service operations in application layer code running on the local server.
This is a local service. Methods of this service will not have security checks based on the propagated JAAS credentials because this service can only be accessed from within the same VM.
Conclusion
Use OrganizationUtil if you care about transaction i.e. have to update multiple tables in a transaction then use this.
Use OrganizationServiceUtil if you creating Organization outside liferay or if you need permission checks & you don't care about transaction (i.e. transaction with your custom code)
Use OrganizationLocalServiceUtil if you are not using a web-service and you don't care about transaction or permissions.
Hope this gives you a fair idea. Let me know if it is still unclear.
Application Service fulfills the commands issued by clients ( ie presentation layer ) by making and coordinating calls to the Workflows, Infrastructure Services, Domain Services and Domain Entities.
Is it a common practice to also have few Domain Services that do similar job as Application Services, meaning they also make and coordinate calls, only difference being they do it at a more fine-grained level ( ie they only make and coordinate calls to other Domain Services and Domain Objects )?
If yes, any ideas how fine-grained should these Domain Services be?
Thank you
Domain Services contain domain logic that doesn't particularly fit into any Entity, or that spans across several entities.
One often quoted example is a FundsTransferService. Transferring funds doesn't seem like the responsibility of the BankAccount entity, because that would mean the source account can modify the target account's balance (or the other way around) which seems awkward and might be dangerous. A dedicated TransferFunds() method in a FundsTransferService allows for better separation of concerns and channels all funds movements in a single place.
In that regard, you could say Domain Services coordinate calls on entities and other services, but not in the same sense that Application layer services do IMO. Oftentimes, Application layer services are just boilerplate procedural code while Domain services contain real business rules.
only difference being they do it at a more fine-grained level
I wouldn't say Domain services are more fine-grained than Application services. They are essentially just in different layers. It's like saying that a Repository is finer grained than a Controller... usually granularity is a measure of to what extent one cohesive operation is split up in smaller parts vs just a big procedure.
If necessary, a factory can access elements of the infrastructure to build an object?. In a particular case, I have an object that I need to add email signature that is stored as a parameter in the configuration layer of the application.
In DDD, a Factory is at the same architectural level as a Repository, but for creating new objects instead of loading existing objects. So it can call infrastructure services just like the repository.
There is no one correct answer to this problem. If the factory itself is part of your application layer this should be fine. You can also add an application service that hands the email signature down into your domain when needed.