5

Unsure if the question is too broad, or opinion based. Though will ask anyway.

I'm currency reading through Microsofts "Architecture eBook", found https://www.microsoft.com/net/learn/architecture. It has a supporting solution that is found on Github, https://github.com/dotnet-architecture/eShopOnContainers

The sample application provides different patterns to implement within your microservices, along with a collection of different technology and infrastructure.

This leads me to my question.

When looking at the Ordering.API project (https://github.com/dotnet-architecture/eShopOnContainers/tree/dev/src/Services/Ordering) the author has chose to put their Domain and Infrastructure code within separate projects to the microservice API that is using them.

This image shows 3 of the services, with the ordering one implemented with multiple projects

enter image description here

Oddly, the project used to be split up further; having an Ordering.Application project too, which is now part of the Ordering.API project. This out of date image in the docs demonstrates this.

enter image description here

Given that Microservices should be self contained in that they have a defined bounded context, and these domain models should not be used outside of this microservice what would be the benefit of structuring the project like this, as opposed to a folder structure within the Ordering.API project?

Improve this question
1
  • Just to share my experience with you: I worked on a solution which was supposed to be microservices and because of that there were many small projects. These small projects were meant to be deployable as atomic pieces. But the reality was far from the architecture. Things were tightly coupled. Not only that, the shop never ever, not even once deployed the DLLs on their own. They either built and deployed everything or nothing at all. So moral of the story: If you want to deploy in small atomic self contained units, then go for it. Otherwise, well I will let you know decide that.
    – CodingYoshi
    Commented Oct 25, 2017 at 2:02

1 Answer 1

Reset to default
4

  1. Quicker builds. If you have a single project for your microservice, it has to recompile everything (compiler optimizations notwithstanding). If you split your code into multiple projects, only the project you're changing and the projects that depend on it are recompiled

  2. More provably decoupled code. Even in microservices with narrow, isolated functionality, the fundamentals of decoupled code still apply. When you have your different concerns in different, independent projects, it is much easier to verify that you've separated your tiers in an organized way. For example, say you're using an ORM for data access. Without using projects, how easy is it for you to prove that you're not using the ORM right in your controller? With projects, your controller is in a different binary than your data access layer, so it's pretty trivial to prove: your controller project doesn't even have a reference to it!

  3. Easier unit tests. With your stuff separated out into projects, you don't have to include references to all of the crazy third party frameworks you're using for data access or web hosting when you just want to test your core business logic. Granted, in a perfect world you should have 100% code coverage, but we're not in a perfect world. The harder it is to test the simple things, the less likely it is they'll be tested.

  4. Smaller deployments. .NET projects, more or less, translate to DLLs on the output side (this is a simplification, but in general, this is the end result unless you specifically avoid it). When you only change one project, you only have to redeploy one DLL. (Note that this is a terrible reason to choose projects vs. folders since you should be using automated builds/deployments anyways, but it is a reason nonetheless!)

Improve this answer
4
  • since you should be using automated builds/deployments anyways -- Unless you shouldn't. I love the idea of having continuous deployment everywhere, but it takes significant time and effort to set up and maintain, and some small shops can't justify the cost.
    – Robert Harvey
    Commented Oct 24, 2017 at 14:48
  • 1
    @RobertHarvey In my experience, automated builds and deployments are fairly cheap and/or easy depending on your ecosystem (easy in a TFS ecosystem, cheap and easy in a Git/Jenkins ecosystem). Note that I didn't say the automated deployments should go to production ;) Even deployments to a dev server or local machine done by myself for my benefit have been life changing for me. I went from fearing deployments to having no concerns at all. Even if something went wrong, the act of creating the deployment process ensured I knew the system well enough to fix any problems.
    – bvoyelr
    Commented Oct 24, 2017 at 15:10
  • There's a lot you can do with automated scripts and tools like Cruise Control to ease this process considerably. I don't know that I'd call that Continuous Integration, though. Maybe CI Lite or Poor Man's Automated Builds. If you're just talking about helper scripts, you're right; changing your project folder arrangement just to placate your scripts is probably a terrible idea. Your scripts should be bending to your project structure instead.
    – Robert Harvey
    Commented Oct 24, 2017 at 15:19
  • Thanks @bvoyelr. They're all really well thought out reasons. I am personally a proponent of splitting out the tiers across projects, though as I venture towards microservice architecture the lines blur. I can foresee use of static analysis tools to ensure these separated projects don't make their way into anything else.
    – Darren Wainwright
    Commented Oct 24, 2017 at 16:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.