We will need a place where we need to place this "set of base classes and interfaces" mentioned in the previous section. We might argue if these things are required at all. They are not required to start a simple "Hello World" style project, but as we go along, we will need to create more abstractions.

Also, we will need some components that will allow our domain model to work with things like database, message bus, web server and so on. According to onion architecture principles, these are adapters. Our project, in the end, would need to have a collection of adapters for all pieces of infrastructure that are being used.

You might rightfully ask - are we going to build a framework? Aren't frameworks considered evil and shouldn't they be avoided? Well, we should take everything with a grain of salt and have a set of useful abstractions for our domain object and infrastructure would greatly help us while moving along. Also, we definitely will need to build some of the adapters, and although these can be separated in the own libraries, which will connect to our abstractions (hence ports and adapters),  for the reason of simplicity we will put most of these things in one project, and this project will be called Marketplace.Framework. You can choose any other name for this project if you don't like the name framework, but in this book, we will be referencing it a lot, so I hope you don't get confused.

Most of the abstractions and implementations in this framework would be production-ready by the end of this book. And unlike third-party frameworks, you keep full control on what is inside it and how it works, so this should make it a milder evil even if you don't like frameworks at all.

Many DDD practitioners keep telling the mantra "you ain't need DDD framework" and this is partially true, but people always need to have some baseline for their applications to speed up the development. We use .NET Framework, built by Microsoft, and not creating all these classes from scratch for every project. When we get to the point of having a set of useful abstractions and components in our framework, we can use it, or something similar to it, in some other project and be entirely in control.

So, to finish up this section, add a class library project to the same solution. The framework for it should be netstandard2.0 (or later), just as it was for the Marketplace.Domain project. Call this new project Marketplace.Framework.