Hey @redbull,
I feel that with every answer I will provide, there’s a caveat: It always depends.
That’s what we always tell with the Workshop on GitHub, which is the SOA Done Right workshop, that this repository is far from any real representation of a system. But during the workshop, we want attendees to be able to press [F5] and everything should just run. If we tell them to set up their machine with a build pipeline and NPM and much more, then attendees would only learn how to do that, instead of get an idea of how a system or application would be developed. Like how service boundaries translate to actual code and how the different components communicate between each other. And not so much the structure of the Git repository, the Visual Studio solution, etc.
With that, let me try to answer your questions.
-
A service can have 1 repository, but will likely have many more. But that also depends on how you set up your projects, how many components there are inside it, etc. For example, just looking at NServiceBus, you might have 10 message handlers. Do you split them over logical endpoints? How many? How many projects does this result in? Does every project have one or multiple NuGet packages that are first deployed? Etc, etc.
So the short answers is that likely one service will consist of many projects and likey more Git repositories.
-
I personally can’t remember that sentence. Was it not the other way around? That everything should go into a service and nothing should be left?
As Udi explains during the course, there are multiple architectural views.
In the logical view, some logic belongs to ServiceA and other logic to ServiceB. This could mean that in the development view , this results in several controllers. Sometimes it’s technically very hard, if not impossible, to separate this technically. The question would then be, how badly do you want to remove as much coupling as possible, given the effort it takes to achieve this? But remember there are different ways of looking to an architecture. The physical view might be completely different, where the boundaries are very hard to identify, because there are just a bunch of assemblies that make up your website.
IT/OPS is one of the services. One of its tasks is to identify requirements and decide what of those should go into which service. As Udi explains, this is usually where the architects, etc. mostly work with. It also contains infrastructural related code, as I like to call it. As you can see in the workshop repository, this is the ViewModel Composition code and the code that executes the integration with the 3rd party. Something needs to be in place to make sure the components from multiple services form a whole and form the application. Preferably without knowing anything of any of those components. The ViewModel Composition code is a great example of this.
As a last remark, the fact that there are no NuGet packages for controllers or anything in the Workshop GitHub repository, is again because it would take way too much work for attendees to set all of this up. Initially there was a “build event” in one or more project to copy assemblies to the appropriate place. However that caused some issues, so we replaced those with “project references”. This is far from ideal to get the idea across, but at least it works. Normally we explain this during the workshop.
Let me know if this makes sense or you have additional questions.