Есть какие-нибудь советы относительно шестиугольной архитектуры с сериализацией в качестве основной метафоры?

Question

У меня появилась возможность переписать ядро приложения внутренней разработки, которое мой работодатель использует для контроля документооборота.Мой список "основных" требований выглядит примерно так:

• Упростите импорт / экспорт в различные форматы (общим фактором является коллекция файлов + довольно обширные метаданные).
• Упростите добавление новых полей (присутствие которых зависит от данных, а не от глобального характера) на нескольких уровнях
• Внедрить несколько новых функциональных возможностей, которые нарушают фундаментальную предпосылку старой системы (по сути, структура метаданных, окружающих документы, претерпевает радикальные изменения).
• Поддерживать способность жестко контролировать отношения и соглашения между документами и метаданными

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

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

Answer 1

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

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