[Question] Best practice(s) to start a similar project from scratch?

[chess-equality]

Hello,

First of all thank you for creating this wonderful resource!

In our project we have separate teams working on the Web app, Xamarin app, and the backend microservices app, respectively, and I would like to ask if it is optimal to put all the sub-projects under one main solution project just like in eShopContainers? What would be the challenges if we separate them? Our thinking is that each team would only be working on the codebases they own, but then would there be any issues when we integrate them together?

Also I would like to ask how to start such project? E.g.:

1. Create main solution project.
2. Create BFFs sub-project under main solution project.
3. Add microservices sub-project under main solution project.
4. Etc...

Thanks.

[eiximenis]

Hi! I am contributor on eShopOnContainers but what I'll say here is just my opinion, so don't take it as an official advise from Microsoft :)

Using a single repo is good for simplicity and when is a single team. eShopOnContainers has some contraints, and enforcing these constraints imposes a set of practices. Some of these constraints are:

• Full F5 experience from VS
• Simplicity to make it easy to newcomers "start with eshop".

This made us to use a single repo, because using multiple repos makes hard to have a F5 experience from VS.

Given said that, if you have separated teams I'll tend to use separate repositories (at least one per team). This forces to avoid having inter-dependencies between teams and helps to isolate their. Of course this implies an extra-work at devops phase, to make all other components easy-available to the rest of teams (CI pipelines to, at least, publish al docker images to some registry usable by all developers). Also a CD pipeline working on some "production environment" (probably an orchestrator) is highly recommendable. You should deploy on this environment and perform the integration tests on it.

The most important challenge when using separated repos is to make easy-available the changes from one team to all others (this is the devops work) but also having all communication mehcanisms to share the "implicit contracts" between the services. This means that apis should be versioned at each breaking change.

Hope this helps :)

[mvelosop]

Hey @eiximenis!, @chess-equality

That's right, (and this is neither official from Microsoft!) one single repo is great just for eShopOnContainers as a sample app.

Using this structure for a real production app would probably add more complexity and you don't need that.

I'd only add that a good way to share components, like building blocks and similar, between teams is by using private NuGet packages, published in Azure DevOps.

Perhaps it'd be good if you took a peek at this related issues:

• https://github.com/dotnet-architecture/eShopOnContainers/issues/86
• https://github.com/dotnet-architecture/eShopOnContainers/issues/411
• https://github.com/dotnet-architecture/eShopOnContainers/issues/724

Hope this helps!

[CESARDELATORRE]

@chess-equality, @eiximenis - This is Cesar, from Microsoft, so you can take my comments as official recommendation. :) In eShopOnContainers we use a single solution and repo because it is an asset for learning, so folks want an F5 experience and test everything. But for sure, for a real and larger application where different and independent dev teams are working on the same end-to-end application, I would recommend one repo per microservice. That approach makes sure that the microservices are really autonomous and independent.

But, as Edu mentioned above, "you'll need extra-work at devops phase, to make all other components easy-available to the rest of teams (CI pipelines to, at least, publish al docker images to some registry usable by all developers). Also a CD pipeline working on some "production environment" (probably an orchestrator) is highly recommendable. You should deploy on this environment and perform the integration tests on it."

But, yes, if multiple/independent development teams are working on the solution, or even if you want to make sure from the beginning that microservices are truly independent, we recommend one repository per microservice or bounded-context (sometimes a "Business microservice" means a few projects, too, like the "Ordering Microservice" in eShopOnContainers).

Hope it helps,

[uboznikov]

Could you please expound more what is an orchestrator and how to use it; just a simple example would do.

Also how to start the project with VS 2017 (the second part of my question above)?

Again thanks all, I'm learning great :-)

[CESARDELATORRE]

Please, check this info from our guidance: https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/scalable-available-multi-container-microservice-applications

Basically, I'd recommend you to use Kubernetes. Then, on Azure it is called AKS (Azure Kubernetes Service).

To start the solution in Visual Studio and run it on plain Docker you just need to follow these instructions: https://github.com/dotnet-architecture/eShopOnContainers/wiki/02.-Setting-eShopOnContainers-in-a-Visual-Studio-2017-environment

[chess-equality]

To start the solution in Visual Studio and run it on plain Docker you just need to follow these instructions: https://github.com/dotnet-architecture/eShopOnContainers/wiki/02.-Setting-eShopOnContainers-in-a-Visual-Studio-2017-environment

@CESARDELATORRE I meant how to create such project from scratch / blank Visual Studio workspace? Thanks.

[mvelosop]

Hi @chess-equality, Do you really mean from scratch scratch? a blank workspace? in a GitHub issue? 😲

Wow, that would be more like a consulting project!

Anyway, you're lucky enough that @CESARDELATORRE has already written the text book you need and you can get it in PDF or online.

Hope this helps.

[ardalis]

I have a solution starter kit GitHub project that follows similar architecture principles to the eShopOnWeb project. It could be used as a starting point for each microservice in an eShopOnContainers-style application, as well. You'll find it here: https://github.com/ardalis/CleanArchitecture

[mvelosop]

Hi @ardalis, good to know that 👍

[chess-equality]

Hi @chess-equality, Do you really mean from scratch scratch? a blank workspace? in a GitHub issue? 😲

Wow, that would be more like a consulting project!

Anyway, you're lucky enough that @CESARDELATORRE has already written the text book you need and you can get it in PDF or online.

Hope this helps.

@mvelosop My apologies, but I'm a reconnecting with .NET/C# after 13 years, so I'm quite a beginner again. Yes I'm reading the PDF, but I have not found a summarized way of creating a project from scratch. As I have illustrated in my first post, I'm just asking for a summary. Also in the README:

Sending feedback and pull requests As mentioned, we'd appreciate your feedback, improvements and ideas. You can create new issues at the issues section, do pull requests and/or send emails to eshop_feedback@service.microsoft.com

So from instruction from above I followed that I could ask my question in the issues section (if there is a forum, I would gladly ask there). But thanks for all the help so far, especially @CESARDELATORRE !

[chess-equality]

I have a solution starter kit GitHub project that follows similar architecture principles to the eShopOnWeb project. It could be used as a starting point for each microservice in an eShopOnContainers-style application, as well. You'll find it here: https://github.com/ardalis/CleanArchitecture

@ardalis Thanks, looks like a very good resource for beginners :)

[mvelosop]

Hi @chess-equality, ok, that clears things out 😅

I thought you meant creating a microservices app like this from scratch!

In that case, I'd suggest you take a general look at https://asp.net and then go on to https://docs.microsoft.com/en-us/aspnet/core/?view=aspnetcore-2.2

There's an excellent set of tutorials that are great to understand the basics.

I'd suggest that you get @ardalis repo after you understand the basics from the tutorials.

BTW, I would also recommend you to check @ardalis podcast

Hope this helps.

[chess-equality]

Thanks @mvelosop and all for all the help, I have created our project with one main solution then I initially added a "sub-solution" for the gateways/microservices mirroring the structure of eShopOnContainers, working all good so far in local Docker.