Я бы придерживался Вариант 1, поскольку каждый домен должен имитировать схему именования имен дочерних имен.
Если вы звоните BusinessName.Common общая библиотека во всех доменах (то, что вы называете единицы ...), конкретный домен общие члены всей области, таким образом, ваша схема именования должна быть BusinessName.[DomainName].Common, BusinessName.[DomainName].Services.
В любом случае, позвольте мне добавить больше значения для этого ответа. Вы сказали, что в проекте/пространстве имен будет общих объектов, классов, утилит. Я не согласен с этим. A общая библиотека должна быть библиотекой перекрестного слоя (по вертикали). Я советую вам организовать такое решение таким образом:
BusinessName.Common: Код инфраструктуры. Любой код, связанный с доменом, не должен быть здесь. Классы, интерфейсы и перечисления здесь должны использоваться с любого уровня и уровня.BusinessName.Domain: Общие сущности и службы домена. Я бы поставил здесь общие интерфейсы домена, абстрактные классы, базовые классы ...BusinessName.Domain.[SomeDomain]. Например, BusinessName.Domain.Medical. Я бы поставил здесь все о домене. В определенном домене нет каких-либо общих объектов в каком-либо другом домене, поскольку это приведет к поражению цели организации вашего проекта в доменах.
В своих проектах я предпочитаю использовать Shared идентификатор вместо Common, но это только мое мнение.
, так что в чем проблема .. почему бы не придерживаться того же соглашения об именах 'BusinessName.Common'' BusinessName.Services' BusinessName.Common.Medical' и BusinessName.Services.Medical' в чем проблема .. вы знакомы с тем, как работают пространства имен.? – MethodMan
Да, я знаком с тем, как они работают ...Я добавляю новый блок и хочу вводить имя для подблока. –
Если вы знакомы, то вы ответили на свой вопрос. В основном это ваше собственное мнение при создании пространства имен .. какая большая проблема .. ?? – MethodMan