Which layer I should add scheduler project in domain driven design architecture?
I am thinking of adding scheduler in Distributed service layer and business login inside application services layer.
Here is the solution design I am thinking of:
Presentation Layer
UI project
Distribute Service Layer
Application API
Scheduler
Application Layer
Application (Application services for Application API and Scheduler logic)
DTO
Domain Entity Model
Project Domain (Domain entities specific to project)
Scheduler Domain (Domain entities specific to scheduler)
Data Persistence
Data Access Project (Repositories)
Data Access Scheduler Domain (Repositories)
Cross Cutting Infra.
Authorization
Logging
Any help is appreciated.
Since now I've implemented this kind of component in the Presentation layer, on the same level as the UI. These components are awaken by cronjobs at regular times then they call Application services in order to send commands to the Aggregates. Then, the Aggregates, if necessary and allowed, perform the changes to the system state.
Related
I am going through Reliable Services and Reliable Actors. I have gone through online documentation but few concepts are not clear to me.
With what I understood:
(1) Reliable Service is a programming model and comprises of Stateless and Stateful services. Reliable Service provides highly available set of classes called as: Reliable Collections.
(2) Reliable Actors is a programming model which comprises of Stateful services which utilize single thread for execution. Reliable Actors cannot be Stateless.
I want to know when to use:
(a) Stateless Service
(b) Stateful Service, and
(c) Reliable Actors
What type of services are best suited as single-threaded application?
It will depend on your application and how it is strructured I imagine that you are talking about Service Fabric Here since you just put a tag and not on the question itself.
For the reliable services you have 2 option they are statefull services iagine this as a webpage that wants to keep the state of the client (if you are used to .net imagine this as a persistent session state of having the affinity cookie enabled on your application) basically what you are doing ti tis persisting the information that comes trough this services in order to do that you should be using reliable collections.
Stateless services are basic api calls that will get the response from a service or do some work and return the response back. the classical case it is imagine that you have a services that will do the sum of 2 numbers it doesn't need to implement state it will do the work and retuirn the reponse back but this can be used for services that store the state outside of the service itself.
Reliable Actors are build on top of the reliable services that are statefull they are an implementation of the actor model but built on top of the statefull reliable services. THey just add some utilities on top of the statefull services.
you can read more details on the service fabric implementation of those model on : https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-overview
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?
I am designing the architecture for an Azure application, and I have a few questions on how to proceed. I am familiar with the basics of Azure, but have never built and deployed an Azure application before. I have extensive experience with conventional non-cloud, web-hosted applications, though.
My application will be the usual database-centric business system with a web user interface. We want to start very small and grow it slowly as we gain user base. I am planning to use an SQL Azure database for relational storage as well as blob storage for documents and the like. These will be accessed by a Data Access Layer, which in turn will be operated by a Business Layer. The web user interface will be built using ASP.NET and will rest on the Business Layer.
All this is very traditional, but I wonder how well it fits with Azure. I have some specific and inter-related questions:
I see the Data Layer and Business Layer as part of an Application Tier that can be deployed on a worker role, whereas the web user interface can be deployed as a Front-End Tier on a web role. Is separating the business and presentation logic like this a wise decision on Azure?
Having said the above, having two separate roles wouldn't make sense while the user base is very small, so I would rather deploy everything together on a single web role until we get bigger. What do I need to do to make sure that these two tiers can be easily reconfigured to work as either one or two roles with any recoding?
The communication between the web user interface and the Business Layer must be fast; I am concerned that it won't be very fast especially when these two are deployed as separate tiers on different web/worker roles. What is the best communications mechanism in Azure that I should use? I have considered queue storage, service bus and virtual network, but I am not sure how to make a decision here.
I have been reading some best practices posts and documents online, but they seem to address advanced issues. I would rather like to have answers to these quite basic concerns in the form of pointers to best practices articles or the like. Thank you.
I want to create a project in Asp.Net MVC with C# using Entity Framework with BAL and DAL layers ? There are two module here User and Admin module with custom login feature. Admin can add run time columns in the existing database with add, edit update the records such as any report.
The record display to the users.
If you have any such type of reference article/project (N-tier architecture) let us know please.
When i create MVC projects, i usually follow this structure:
UI Layer - This will be the actual mvc project and will interact with the service layer
Service Layer (BAL) - This will hold all your business logic classes and will interact with the data access layer. This layer will expose services the UI Layer can make use of
Data Access Layer - This will hold all classes related to data access. As you are using entity framework, your DbContext can live here
Entities - This will hold all entities used in your solution
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.