Если вы разработчик, то точно знаете, что придумать название для проекта, метода, переменной или класса, на самом деле не такое уж простое дело. Особенно если вы работает в команде. В этой статье я опишу названия проектов (projects) для одного решении (solution), которые я обычно использую или стараюсь использовать.

Как назвать проект?

Если у вас есть всего один проект, и вы с ним работаете изо дня в день, то, по большому счету, для вас нет особой разницы как называются проекты. А если у вас десятки проектов, и вы пишите код, который может быть переиспользован в разных проектах, то соблюдение правил именования проектов, вам может существенно облегчить процесс поиск нужно файла, класса, функуционала. Во всяком случае, мне очень помогает в поиске возможности найти общие моменты для вынесения их в сборки (nuget). В любом случае, придерживаться определенного порядка никакого зла не принесет, а пользу вы точно почувствуете позже. Порядок должен быть во всём!

Чистая архитектура

Чистая архитектура (или Clean Architecture или CA) - на мой взгляд, очень полезная вещь, хотя бы потому, что заставляет разработчика правильно выстраивать зависимости в проектах для одного решения. Это помогает избежать рекурсивной зависимости в классах и модулях. Неправильные связи, порой, могут привести к невозможности реализации какого-нибудь нового функуционала.

В последние время модная тенденция именовать проекты в соответствии с подходом Clean Architecture сводится на "нет", потому что это не чёткая инструкция по разработки ПО, а всего лишь абстрактная модель, которой надо придерживаться при разработки ПО. Однако, если инструкции не очень чёткие, то их каждый понимает по-своему. Неудивительно, что именуют все по правилам CA, а то что в них лежит может существенно разнится с тем, что каждый вкладывает в эти понятия. Я использую подход, описанный CA, но названия обычно использую немного другие, чтобы точно понимать "что", "почему" и "где".

Напомню, как выглядит Clean Architecture в формате картинки у ее основателя Роберта Мартина:

Правда, всё сразу понятно?

Пример

Если посмотреть на картинку, то сразу понятно, что ничего не понятно или почти ничего. Но надо понимать, что именование проектов очень сильно влияет на namespace в C#, потому что имено на названиях проектов он (namespace) и строится. Итак, как и почему я именую проекты в своих решениях.

Для начала namespace для Solution. Например, Calabonga.Catalog.sln, структуту можно посмотреть в github.

1. Назавание solution начинается с Calabonga.
   Calabonga - это название организации, своего рода уникальный идентификатор компании или разработчика, что бы чётко разделить все существуюшие сборки от моих.
2. Название через точку включает в себя продукт, например, Catalog.
   Обычно, я использую не более двух слов в название продукта, который будет реализован в решении.

Далее, после точки следует название проекта, сборки, если хотите, которая определяет тип взаимодействия между проектами.

Теперь немного подробнее о том, как устроено решение и какие проекты в нем для чего служат.

1. Сборка с примитивами Calabonga.Catalog.Core.
   Другие варианты названий для этого проекта: .Primitives, .Contracts, .Interfaces.
   В этом проекте находятся простые примитивы, но при это общие и публичные, которые используются во всех проектах системы или почти во всех. Например, перечисления (enum), интерфейсы приложения (типа IProfileService) и так далее.
   Чаще всего я использовал .Core, но когда вышел NET Core стал использовать .Contracts.
2. Сборка с сущностями Calabonga.Catalog.Models.
   Другие варианты названий для этого проекта: .Entities, .Domain.
   В этом проекте находятся те классы, которые которые хранятся в БД. Это если по-простому.
   Чаще всего я использую .Entities.
3. Сборка для доступа к хранилищу данных Calabonga.Catalog.Data.
   Другие варианты названий для этого проекта: .Application, .Database, .UseCases, .Infrastructure. Кажется совсем неочевидные названия, но это действительно так. В противном случае, придется разбивать на большее количество сборок (например, .Data и  .Application, и это иногда оправдано). В этом проекте находятся классы, которые обслуживают .Entities на предмет чтения из хранилища, манипуляции данными и сохранения данных обратно в хранилище. Опять же, если по-простому.
   Чаще всего я использую .Data.
4. Сборка представления Calabonga.Catalog.Web.
   Другие варианты названий для этого проекта: .API, .WPF, .Client, .Blazor, .MVC, .Host.
   Этом проект являет собой ничто иное как клиентское приложение, где находятся формы представления, классы их обслуживаюшие и прочие причиндалы, без который это приложение не будет работать. И снова, это если говорить простыми формулировками.
   Чаще всего я использую .Web.

Заключение

Правила - упрощают жизнь, хотя правила бывают разные. Возьмите, например, договоренности в ASP.NET MVC проекте, или даже правила дорожного движения. Кто живет не по правилам - рискует попасть в неприятную ситуацию. "Расставлять всё по полочкам" - хороший тон. Порядок в голове - порядок в коде. Пишите правильный код!