Question: how would you transform this into a multi-project solution?

[SanderDeclerck]

First of all, great sample to illustrate CQRS! I hope you are allowing questions and I hope this is a good place to put them.

In a larger-scale application, you would probably make multiple projects. Starting with something like:

• Website
• Logic
• Data
• Domain

How would you refactor this sample into multiple projects?

Especially, where would you place the requests, request handlers, validators and models since all of them seems to be tightly coupled (also with the domain classes).

If we look at the Instructor feature. Both the Instructor domain object and the CreateEdit.CommandHandler use the CreateEdit.Command. Does this make the command part of the domain? Or do we create another project where commands and models go to?

[michael-wolfenden]

In a larger-scale application, you would probably make multiple projects

Why? What problem are you trying to solve by making multiple projects?

Jimmy wrote a blog post regarding seperation via projects here https://lostechies.com/jimmybogard/2012/08/30/evolutionary-project-structure/

[SanderDeclerck]

Why? What problem are you trying to solve by making multiple projects?

Mainly to create clear boundaries between different layers in your project so you can restrict dependencies. That way you have a better control over dependencies between different parts of your application as your project grows.

Eg: now it is possible for your data-logic to have references to parts of the application that are built around the view/display of information.

Let me turn that question around: what is the downside of creating multiple projects?

[michael-wolfenden]

An assembly is a unit of deployment, do you plan on deploying your projects independently?

There are a number of issues with having multiple projects. This article https://codurance.com/2015/03/23/multiple-projects-in-visual-studio/ summaries it better than I can.

At the end of the day, for me, splitting a solution over multiple projects just creates a ton of busy work that ultimately adds very little value.

[SanderDeclerck]

Just read the article. Point taken.

Let's say we have another deployment. Let's say we wanted to add a public REST api that is deployed independently from the website. If you don't create projects for seperate layers in your application, you would have duplicate a lot of code around logic and data-access.

So in that case, the question still remains - how would you seperate logic from view?

PS: But still, I feel more confident when dependencies that are undesirable are restricted in some way. Maybe there is another way I am not thinking of or I don't know of.

[michael-wolfenden]

Right..

So lets say we just has a website for ordering. we would start off with a solution structure or

- Orders.Web

If we then added an api, we would add two more projects, so the solution now looks like

- Orders.Api
- Orders.Web
- Orders.Shared or Orders.Common or Orders.Core

The shared project is where all the common code, logic goes. As far as projects go though, that is it. It would be very rare for us to have anymore projects than this other than a Test project and maybe a Service project if we had bus message consumers or background workers.

As for undesirable dependencies, if you really wanted to you could write convention tests (unit tests) that use reflection to verify that certain types don't depend on other types etc.

[SanderDeclerck]

I didn't really mean to start a discussion about if you should, or should not split up into multiple projects. I just would like to know, if you wanted to, how would you.

So how would this scale over multiple projects?

Maybe we can just agree to disagree?

[jbogard]

If I do multiple projects, it's not for layers, but for modules.

So maybe Orders.Checkout, Orders.CustomerView etc.

On Tue, Aug 8, 2017 at 3:54 AM, SanderDeclerck notifications@github.com wrote:

I didn't really mean to start a discussion about if you should, or should not split up into multiple projects. I just would like to know, if you wanted to, how would you.

So how would this scale over multiple projects?

Maybe we can just agree to disagree?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jbogard/ContosoUniversityCore/issues/15#issuecomment-320894302, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGYMif_pSTz97Rr0sN20zxu1govBKErks5sWCItgaJpZM4OwRnT .

[mwhelan]

@SanderDeclerck . I would organize it similarly to how it is now, moving the folders to their own project. Using DDD layers you could have something like this:

Contoso.Web Contoso.Application Contoso.Domain Contoso.Infrastructure

Like you, I like to have clear boundaries between layers.

[jbogard]

Meh, not a lot of value to that in my experience. Slices not layers 😁 On Tue, Aug 8, 2017 at 10:50 AM Michael Whelan notifications@github.com wrote:

@SanderDeclerck https://github.com/sanderdeclerck . I would organize it similarly to how it is now, moving the folders to their own project. Using DDD layers https://ajlopez.wordpress.com/2008/09/12/layered-architecture-in-domain-driven-design/ you could have something like this:

Contoso.Web Contoso.Application Contoso.Domain Contoso.Infrastructure

Like you, I like to have clear boundaries between layers.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/jbogard/ContosoUniversityCore/issues/15#issuecomment-320998717, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGYMgdsJxcXZvpa02AN3cJsRXYKuyuaks5sWIPWgaJpZM4OwRnT .

[mwhelan]

To be honest, I've been using these layers for so many years I think it's as much out of habit as anything else. I do like the feature folder organization in the web project rather than the traditional Controllers etc. - so I'm half way there I guess. :-)

@jbogard, in your professional projects do you just have all the slices in the one project then, like in this sample? When you add a project like the Orders.Checkout module, would that have the whole slice with views and code, or just the code with the views still in the web project?,

[jbogard]

Nah, I don't go too far with the modules tbqh, but those are basically Areas in MVC. Or if you're doing SPA, it's a bit easier to combine everything together. MVC makes some assumptions on view locations and it's not terribly configurable, so I tend to work with the norms there.

On Tue, Aug 8, 2017 at 11:36 AM, Michael Whelan notifications@github.com wrote:

To be honest, I've been using these layers for so many years I think it's as much out of habit as anything else. I do like the feature folder organization in the web project rather than the traditional Controllers etc. - so I'm half way there I guess. :-)

@jbogard https://github.com/jbogard, in your professional projects do you just have all the slices in the one project then, like in this sample? When you add a project like the Orders.Checkout module, would that have the whole slice with views and code, or just the code with the views still in the web project?,

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jbogard/ContosoUniversityCore/issues/15#issuecomment-321011469, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGYMl0L-ZNTYFKO2XMr3UFmvFO266Yvks5sWI6TgaJpZM4OwRnT .

[mxmissile]

My go to reasoning: http://codebetter.com/jeremymiller/2008/09/30/separate-assemblies-loose-coupling/