Моделирование предметной области против реляционного моделирования
Существует несколько основных способов выражения наших идей в области бизнеса
Я думаю, что важно сначала установить, что домен не зависит от конкретных технологий и / или парадигм программирования (например, OO, FP, реляционный). В этом ответе предполагается, что вы уже определили свой домен отдельно, например, используя методы DDD, и теперь хотим использовать реляционную базу данных для ее хранения.
Сильные стороны реляционной модели
Реляционная модель была изобретена, среди прочего, для устранения многих проблем, которые были вызваны предыдущими моделями, включая сетевую модель (которая включает в себя модели OO), иерархическую модель (включая модели XML / JSON) или простые хранилища значений ключей. Он имеет много преимуществ по сравнению со всеми альтернативами, что делает его таким популярным на протяжении десятилетий.
По моему мнению, эти сильные стороны указывают на то, что вам следует создать модель базы данных внутри базы данных, которая была создана именно для этой цели. Все остальные модели, включая вашу клиентскую модель, являются копиями этой оригинальной , реляционной модели из базы данных. Таким образом, все остальные модели должны быть получены из него, а не source для него.
См. Реляционную модель, выраженную в DDL, как ваш источник истины
XSD - это то же самое
XML / XSD - аналогичная технология. Ваши данные выражаются в терминах XML, но когда две системы взаимодействуют друг с другом через API на основе XML, XSD (или, например, WSDL, если хотите) является наиболее подходящим языком для определения этой связи.
Если вы хотите привязать свои XML-документы с помощью клиентской технологии, например, JAXB в Java, тогда вы должны генерировать эти классы JAXB из XSD, а не наоборот. Зачем? Потому что XSD является источником истины
Я уже писал об этой теме здесь .