Вопросы по дизайну сервисов приложений

Question

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

Вот мои основные вопросы:

1. Насколько «открытыми» должны быть ваши подписи?Например, лучше ли быть более жесткими с вашими подписями и использовать простые типы в качестве параметров, когда это возможно, или лучше использовать объекты (сообщения?), Которые впоследствии могут быть изменены без нарушения сигнатуры?

2. Если вы хотите раскрыть варианты подписи, например, метод UserSearch, который возвращает список пользователей на основе различных (и иногда необязательных) критериев поиска, лучше:

   A,Используйте перегрузки

   B.Используйте необязательные (или обнуляемые) параметры

   C.Разбейте каждый сценарий на собственный уникальный метод

   D.Используйте сообщения

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

Заранее спасибо.

Answer 1

Хорошие вопросы. Размышление об API очевидно важно.

1) То, насколько открытым будет для меня, будет зависеть от того, кто является потребителем. Если эта прикладная служба используется только в контексте вашего собственного решения и / или команды, то я думаю, что хорошо иметь конкретные сообщения (или, скорее, их интерфейсы) или Dtos (объекты передачи данных). Хотя если это так просто, то лучше придерживаться простых типов в моей книге и определенно лучше, если их употребляют другие. Если их недостаточно, то сопутствующих сообщений, которые предоставляют только достаточно. Опять же, если вы собираетесь распространяться на разные платформы, то простые сообщения простых типов - неплохой путь.

2) Почему бы не иметь объект SearchCriteria в качестве параметра? Это может быть сообщение SearchCriteria простых типов, если вы рассматриваете это как начало шины обмена сообщениями.

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

Answer 2

Джерад, на эти трудные вопросы, на которые вы обычно отвечаете, как вы отметили.

Я лично предпочитаю использовать примитивы в сигнатурах методов, где это возможно.Если мне нужно передать 3+ примитива методу, я определяю пользовательские объекты передачи данных.

Мыслящее существо: если несколько значений передаются вместе, вероятно, они представляют концепцию в вашем проблемном пространстве и, следовательно, должны стать объектом.Например, если вы передаете координаты X и Y методу, я бы порекомендовал создать класс Point или структуру, которая представляет эту концепцию.

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

Итак, я бы ответил # 1 с «не очень открытым» и #2 с А.

Надеюсь, это поможет.