Closed Praveen-Rai closed 5 years ago
This almost seems the same question as #167. 'Organize for feature instead of technology'. I think the answer might be to use both patterns depending on the purpose. If you are supporting an optional plugin. It might make sense to contain all functionality in a single module Use more of a SOA pattern versus more of a MVC or 3 tiered model. Internally your plugin might even have a 3 tier architecture but it is a separate module/service from the rest of the monolithic web app. It usually boils down to your needs and personal/team taste.
@MenaceSan I liked DDD based MVC pattern b'coz it allows to easily add/update components in different layers. For e.g. in the presentation layer i can have both WebApi's and RazorPages, and at some-point in future i can again easily add VueJs based front-end.
On the other-hand, if we look at any community driven project, a plugin mechanism is much needed. For instance WordPress, SimplCommerce. Hence, i am looking forward for a sample that demonstrates a recommended way for such Use Cases. And of course, there will be customization based on individual use-cases, so is the case for EntityFramework Core itself.
Also, you were referring to some existing issue but i think you've put up wrong id. Can you please fix that ?
Any news on this?
Hey @Praveen-Rai @MenaceSan @zHaytam - have you checked out the eShopOnContainers repo? This repo goes about splitting "services" up in to their own projects, as in there is a BasketApi, CatalogAPI, etc.
So in your original question if you wanted to add a payment gateway, or a product rating system, these would become their own microservices.
@efleming18 Sorry i am responding so late, actually i gave a thought on creating micro-services architecture. But creating a service isn't the right choice for everything. Taking my case, i want to build an open-source eCommerce platform with an simple procedure to let end-users install payment gateway of their choice. The expectation is that the gateway integration ( plugin ) will be either developed by the gateway provider or community. The end-user should just upload the plugin and configure it, from the admin panel. And that must suffice.
We do have something simple for .Net Core ( not considering Asp.Net features such as controllers, views, entities etc. ) here https://docs.microsoft.com/en-us/dotnet/core/tutorials/creating-app-with-plugin-support
Further you can refer to below article to understand, how the information is scattered. https://www.codeproject.com/Articles/1109475/Modular-Web-Application-with-ASP-NET-Core
The sample does makes the core Testable, and separates the concerns of WebHost, Database and UI Engine. For me the greater problem is to add new functionalities, infact the separation into 3 layers actually adds work for me. Let's assume for this example itself, we want to add payment gateway or may be a product rating mechanism. I'll have to modify all the three projects for it. What instead interests me is the capability to create extensions and add (register) them to the core ( without recompiling the core, infrastructure and presentation layer ). Example is SimplCommerce
While, i am happy with that kind of solution and having everything related to a module in one assembly ( entities, services, controllers and views ). It contradicts the DDD pattern that way.
Is there a way i can have a modular design in DDD ? If yes, then adding that approach to this sample would be immensely helpful.
FYI .. Thien Nguyen has demonstrated the architecture of SimplCommerece in .Net Conf 2018. S211 - Modular Web Applications with ASP.NET Core - Thien Nguyen