Дизайн многоуровневого программного обеспечения абстракции

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

По существу будет 3 главных уровня классов. Эти два класса должны будут говорить друг с другом. 

Первыми являются входные исходные данные. В настоящее время есть 2 главных типа входных данных, которые производят подобный, но не идентичная продукция. Главная цель этих классов будет состоять в том, чтобы получить данные из двух источников различия и преобразовать их в общий интерфейс для использования в остальной части программы. 

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

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

Настройте код следующим образом, по существу после a [шаблон "мост"](https://en.wikipedia.org/wiki/Bridge_pattern), но с многократными уровнями абстракции.

Входной класс будет абстракцией. В настоящее время два различных средства того, чтобы быть произведенным будут двумя различными реальными классами, и более реальные классы могут быть добавлены при необходимости.

Класс обертки будет a [шаблон "фабрика"](https://en.wikipedia.org/wiki/Factory_method_pattern). Большая часть кода должна быть распространена между различными внедрениями, таким образом, это должно работать хорошо, чтобы обращаться с мелкими различиями.

Выходной класс будет включен как часть класса конструктора. Нет образца, действительно требуемого, поскольку только одна версия будет когда-либо требоваться для этого класса. Кроме того, конструктор, вероятно, будет единичным предметом.