Namespace and class name guidelines

Im having problems naming my classes and services correctly when utils and other help classes are involved.

How would you structure the following:

EventService.cs
EventServiceUtils.cs
EventServiceValidators.cs
EventServiceCoordinator.cs

etc...

I have multiple services with the same needs as the above service. One thought is to separate all of this into a suitable namespace, making it look something like this:

Services.EventService.EventService.cs //(the actual service)
Services.EventService.Validators.DateValidator.cs
Services.EventService.Validators.ParticipantValidator.cs
Services.EventService.Coordinators.ParticipantCoordinator.cs
Services.EventService.ExtensionMethods.Extensions.cs

and so on. Every namespace is of course a separate folder. But this doesnt feel 100%, since there are probably more DateValidators in the other services, which can easily lead to an unwanted reference.

And also the Services.EventService.EventService.cs includes the class name in the namespace, which is no good either. You could use Services.Event.EventS开发者_开发问答ervice.cs, but there is of course already an entity with that name.

This is the domain model.

AppName.Services.Events.EventService.cs //(the actual service)
AppName.Services.Events.ParticipantValidator.cs
AppName.Services.Events.ParticipantCoordinator.cs
AppName.Validators.DateValidator.cs
AppName.Text.Extensions.cs

Points:

• Add extensions to a namespace describing what they are extending
• Add common validators do a general namespace
• Use an app name as the top level (Microsoft recommends a company name per their guidelines)
• I wouldn't put coordinators in a separate namespace if there are just a few.

Microsoft guidelines can be found here: Framework Design Guidelines

You can put validators (and other classes) that are used in more than one service in seperate namespace named eg. CommonValidators.
You can change name of EventService.cs instead of changing name of the namespace - maybe Main.cs or Default.cs?
I am supposing that your service has a contract in interface so this would indicate main/default implementation of service contract.