0

I would like to split my C# Web API project, such that a given feature (or a set of features) are maintained in separate projects. Ideally, I would still like to maintain layered separation as well within each feature package.

Example: I would like to ensure there is a separate API project for each main feature (i.e. a business suite would be separated into sales API, inventory API, payroll API etc. etc.). Each feature would be divided into API (top layer), Models (DTO/ViewModels sent and received from/to the API), Service (business logic) and Tests. There could be more layers, i.e. separate layers for entity classes etc.

There is a certain amount of shared code that must be reused within these projects, both on the top layer (such as error handling, logging etc.) and other layers as well (database connections, repositories...).

Does anyone have a good example of how to do this separation, such that everything is DRY, while maintaining a clear separation of features?

Best regards, Daniel

dabs
  • 727
  • 1
  • 7
  • 23
  • Ideally, this separation would go all the way down to the database, such that a given feature could have its own database. Obviously, this might result in changes to the database schema, where data previously available to feature A is no longer available since it technically belongs to feature B. – dabs Nov 30 '14 at 20:50

1 Answers1

1

What you're trying to achieve sounds very akin to a micro-service architecture. Here are some good links that describe what this means..

http://blog.cleancoder.com/uncle-bob/2014/09/19/MicroServicesAndJars.html

http://martinfowler.com/articles/microservices.html#CharacteristicsOfAMicroserviceArchitecture

The idea is to build your system in a modularised manor, where each component can talk to each other, usually over HTTP. Which seems to be what you want to achieve with having "features" each exposing an API. There is a whole heap of material on this so I'd read around it.

As for sharing code between them, this can be tricky. If you're thinking of this in terms of a modularised system, perhaps the shared stuff should be its own "feature"/"component"/"service"/"module" (whatever you want to call it). Or perhaps there is some stuff you just want to pull out into its own project- if so consider building a Nuget package to share common code across the components?

MartinM
  • 1,736
  • 5
  • 20
  • 33
  • Thanks, any new information is helpful. I'm aware of the microservice concept, although I haven't written one myself. That is why I would really like to get my hands on some sample code :-) – dabs Dec 05 '14 at 20:32
  • I came accross this and remembered this question http://stackoverflow.com/questions/68624/how-to-parse-a-query-string-into-a-namevaluecollection-in-net/ code example: https://github.com/techtribesje/techtribesje – MartinM Dec 12 '14 at 12:25