.NET application built using a microservice architecture with Docker containers. Includes a Blazor WebAssembly e-commerce store with Stripe Elements payment integration.
While planning the features for a simple client application for a fictional Marketing department, I'm seeing scenarios where there will be a need to combine data from orders, discounts and marketing campaigns.
I'm considering whether there would be value in adding another API project that aggregates that information.
For example: if you wanted to see whether a marketing campaign generated additional sales, you would want to see if the number of orders increased during that period and how many of the orders placed during that campaign included discounted products.
But will there be a sufficient number of instances where we need that combined data? Alternatively, if we simply get data from different sources and combine them inside a client app, is it complex and/or slow to accomplish the functionality that we want?
Let's take the example I mentioned above - if we have a client application with a campaigns page that can show orders made during a campaign, we can simply have an order service that gets orders within the campaign's start and end dates. That is not sufficiently complex to justify the additional aggregator project.
Are there potentially more complex scenarios that would justify the additional work though? What if there was a requirement for more complex data analysis, like breaking down sales by brands or models?
I don't have a definitive answer to that question at the moment, and the decision will probably be influenced mostly based on my experience while adding features to this marketing client app.
In a real life scenario, I would probably wait to see how the requirements of the marketing department staff evolved and only if they reached a level of complexity that made client app development onerous would I look at adding an aggregator API. Or if we could demonstrably see bottlenecks when combining data within the app.
While planning the features for a simple client application for a fictional Marketing department, I'm seeing scenarios where there will be a need to combine data from orders, discounts and marketing campaigns.
I'm considering whether there would be value in adding another API project that aggregates that information.
For example: if you wanted to see whether a marketing campaign generated additional sales, you would want to see if the number of orders increased during that period and how many of the orders placed during that campaign included discounted products.
But will there be a sufficient number of instances where we need that combined data? Alternatively, if we simply get data from different sources and combine them inside a client app, is it complex and/or slow to accomplish the functionality that we want?
Let's take the example I mentioned above - if we have a client application with a campaigns page that can show orders made during a campaign, we can simply have an order service that gets orders within the campaign's start and end dates. That is not sufficiently complex to justify the additional aggregator project.
Are there potentially more complex scenarios that would justify the additional work though? What if there was a requirement for more complex data analysis, like breaking down sales by brands or models?
I don't have a definitive answer to that question at the moment, and the decision will probably be influenced mostly based on my experience while adding features to this marketing client app.
In a real life scenario, I would probably wait to see how the requirements of the marketing department staff evolved and only if they reached a level of complexity that made client app development onerous would I look at adding an aggregator API. Or if we could demonstrably see bottlenecks when combining data within the app.