ал об этом некоторое время назад, и недавно он всплыл на поверхность, поскольку мой магазин делает свое первое настоящее веб-приложение на Java.

В качестве вступления я вижу две основные стратегии именования пакетов. (Для ясности, я не имею в виду целую часть 'domain.company.project', я говорю о соглашении пакетов ниже.) В любом случае, я вижу следующие соглашения об именах пакетов:

Функциональный: присвоение имен вашим пакетам в соответствии с их функциональными возможностями, а не идентификацией в соответствии с бизнес-областью. Другим термином для этого может быть присвоение имен в соответствии со «слоем». Таким образом, у вас будет пакет * .ui, пакет * .domain и пакет * .orm. Ваши пакеты являются горизонтальными, а не вертикальными.

Этомного более распространено, чем логическое наименование. На самом деле, я не верю, что когда-либо видел или слышал о проекте, который делает это. Это, конечно, делает меня подозрительным (вроде как думать, что вы придумали решение проблемы NP), так как я не очень умен и полагаю, что у всех должны быть веские причины делать это так, как они. С другой стороны, я не против того, чтобы люди просто скучали по слону в комнатеа также Я никогда не слышал фактического аргументаза делать именование пакетов таким образом. Это просто кажется стандартом де-факто.

Логично: присваивать имена пакетам в соответствии с идентичностью их бизнес-доменов и помещая каждый класс, имеющий отношение к этому вертикальному фрагменту функциональности, в этот пакет.

Я никогда не видел и не слышал об этом, как я упоминал ранее, но это имеет для меня массу смысла.

Я склоняюсь к системам вертикально, а не горизонтально. Я хочу пойти и разработать систему обработки заказов, а не слой доступа к данным. Очевидно, есть большая вероятность, что я затрону уровень доступа к данным при разработке этой системы, но дело в том, что я так не думаю об этом. Это, конечно, означает, что когда я получаю заказ на изменение или хочу реализовать какую-то новую функцию, было бы неплохо, если бы не приходилось ловить рыбу в куче пакетов, чтобы найти все связанные классы. Вместо этого я просто смотрю на пакет X, потому что то, что я делаю, связано с X.

С точки зрения разработки, я считаю большой победой, когда ваши пакеты документируют ваш бизнес-домен, а не вашу архитектуру. Я чувствую, что домен почти всегда является частью системы, которую труднее понять, поскольку архитектура системы, особенно на данном этапе, почти становится обыденной в своей реализации. Тот факт, что я могу прийти к системе с этим типом соглашения об именах и мгновенно по именованию пакетов, знаю, что она имеет дело с заказами, клиентами, предприятиями, продуктами и т. Д. Кажется чертовски удобным.

Похоже, что это позволит вам гораздо лучше использовать модификаторы доступа Java. Это позволяет гораздо более четко определять интерфейсы в подсистемы, а не в слои системы. Поэтому, если у вас есть подсистема заказов, которую вы хотите сделать прозрачно персистентной, теоретически вы можете просто никогда не сообщать ничему другому о том, что она персистентна, не создавая общедоступных интерфейсов для своих классов персистентности в слое dao и вместо этого упаковывая класс dao в только с классами, с которыми он имеет дело. Очевидно, чтоесли Вы хотели показать эту функциональность, вы могли бы предоставить интерфейс для нее или сделать ее общедоступной. Кажется, что вы многое потеряете, если разделите функции вашей системы по вертикали на несколько пакетов.

Я предполагаю, что один недостаток, который я вижу, состоит в том, что это действительно делает удаление слоев немного более трудным. Вместо того, чтобы просто удалять или переименовывать пакет, а затем отбрасывать новый на месте с помощью альтернативной технологии, вы должны войти и изменить все классы во всех пакетах. Тем не менее, я не вижу, что это большое дело. Это может быть из-за недостатка опыта, но я должен представить, что количество случаев, когда вы меняете технологии, бледнеет по сравнению с тем, сколько раз вы используете и редактируете вертикальные фрагменты объектов в вашей системе.

Поэтому я думаю, что вопрос будет задан вам, как вы называете свои пакеты и почему? Пожалуйста, поймите, что я не обязательно думаю, что наткнулся на золотого гуся или что-то здесь. Я довольно новичок во всем этом, в основном с академическим опытом. Тем не менее, я не могу обнаружить дыры в моих рассуждениях, поэтому я надеюсь, что вы все можете, чтобы я мог двигаться дальше.