Моделирование слабосвязанной доменной модели

Question

Вопрос на самом деле не касается DDD, но хотелось бы знать, есть ли способ моделировать слабо связанную модель предметной области. Что я имею в виду под этим? Я работаю в программном редакторе HR, и мы планируем запустить новое приложение с нуля. Мы провели аудит всех проектов, которые мы сделали для наших 150 клиентов, и фактом является то, что мы не можем сказать, что существует одна допустимая модель домена с точки зрения DDD.

Почему? Потому что каждая компания имеет дело с HR по-разному, в зависимости от того, насколько велика компания и т. Д. И т. Д.

Конечно, мы можем идентифицировать общие объекты в области HR, такие как: работа, предложение, сотрудник, навыки и т. Д., Но они не связаны одинаково для клиента A и клиента B. Таким образом, с точки зрения доменной модели, мы не можем сказать, что у сущности A есть ссылка на сущность B, у которой есть набор навыков, потому что это не будет верно для другого клиента.

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

Мы рассмотрели BPM-решения, но они не соответствуют нашим потребностям. С другой стороны, я не могу представить, как вы справитесь с тем, что нам нужно. Фактически, ссылки между сущностями должны быть «сделаны» во время выполнения с помощью некоторого параметра, XML и т. Д. Для каждого клиента. Мы не хотели бы кодировать другое приложение, потому что модель предметной области немного изменилась. Это может быть совершенно безумием, если у вас нет лучшей модели предметной области, но что-то, основанное на обмене сообщениями, может помочь нам.

Хотелось бы, чтобы ваши мысли об этом. Как вы справились с такими ситуациями.

Спасибо

Answer 1

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

Если вы продолжите подталкивать его к все большей и большей конфигурируемости, в определенный момент он перестанет быть моделью домена и вместо этого станет Framework . Затем вы можете использовать Framework для определения конкретных моделей предметной области.

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

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

С большим количеством времени, удачи и навыков вы можете иметь возможность превратить это ядро ​​в предметно-ориентированную платформу .

Answer 2

«Волшебный продукт», мы все ищем один из них :). Я только что сделал один с успехом, используя SOA. Мы хорошо поработали над определением сервисов, а потом немного изменили orchestations или бизнес-сервисы.

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