Я думаю, что ваш «новый способ» ошибочен, поскольку модель представления не должна создавать исключение, которое «каким-то образом» распространяется обратно в модель предметной области. Модель предметной области должна решить это сама.
Сети: как их смоделировать, используя агрегированные корни?
comment
См. FAQ Как задать вопрос и используйте форматирование уровней, чтобы помочь нам прочитать и понять ваш вопрос.
- person Daniel Powell schedule 25.11.2011
comment
Ваши рассуждения о границах транзакций кажутся немного искусственными ... Возможно, было бы неплохо взглянуть на роли в системе, которые будут управлять сетями и узлами одновременно, и насколько быстро каждая роль требует обратной связи (возможно, все это можно проверить в автономном режиме и последовательно) или переключиться на систему, более ориентированную на резервирование (например, заблокировать узлы на определенный период времени и выполнить определенную операцию). Не забудьте поговорить с экспертами в предметной области.
- person JMax schedule 25.11.2011
comment
Да, Ив, ты прав. Обсуждение, написанное здесь, очень искусственно. Он начинается с отношений (один ко многим, многие ко многим) вместо того, чтобы начинать с границ согласованности. Агрегаты - это согласованность, а не агрегация, которая является результатом инкапсуляции, необходимой для создания границы согласованности. Требования согласованности действительно определяются другими вещами, а не отношениями, обнаруженными в модели. Вот где вам нужны эксперты в предметной области. Может быть, агрегаты следует называть «единицами согласованности», чтобы люди сначала думали о согласованности, а не только о родительско-дочерних отношениях ...
- person Yves Reynhout schedule 28.12.2011
comment
Всякий раз, когда в вашей голове возникает необходимость транзакции, подумайте о межбанковском денежном переводе. Сторонники транзакций всегда вызывают банковские транзакции, но нет межбанковской двухфазной фиксации, только возможная согласованность.
- person Jochen schedule 29.12.2011
Ответы (2)
Итак, в этом случае (привязка 1 к 1) вы можете использовать события в модели предметной области, чтобы
NodeA.connect ("порт1") .to (NodeB) .on ("порт3");
NodeA резервирует «порт1» для себя.
NodeA отправляет «portConnectionRequest» в NodeB.
NodeB связывает «порт 3», если он доступен.
NodeB отправляет «portConnectionConfirmed» или «portConnectionDenied».
NodeA получает событие и действует соответственно.
Вышеупомянутое предполагает надежный обмен сообщениями, который легко достигается в JVM, но намного сложнее в распределенной среде, но именно там вам это нужно больше. Если надежная система обмена сообщениями не может быть предоставлена, я думаю, у вас возникнет проблема Византийского соглашения на рука или его часть.
Хорошо, я прочитал и подумал еще об этом, и я думаю, это "правильный" способ сделать это:
person
Niclas Hedhman
schedule
01.06.2012
Ты прав. Модель предметной области должна справиться с этим сама. Мое решение было близко (сигнализирует о событии из модели представления), но не так чисто, как ваше. И действительно, BAP можно решить, выбрав время резервирования. Отлично!
- person Niclas Hedhman; 01.06.2012
Модель предметной области определяет а.о. отношения между сущностями, и мы определяем агрегированные корни, чтобы обеспечить инкапсуляцию и границы транзакций. Хорошо известными отношениями являются отношения «один-к-одному» (объект сущности или значения содержится внутри агрегированного корня), отношения «один-ко-многим» (агрегированный корень содержит коллекцию дочерних объектов) и отношения «многие ко многим». Последнее сложно, потому что отношения «многие ко многим» между агрегированными корнями создают проблемы с границей транзакции. Таким образом, во многих случаях одно направление отношения «многие ко многим» рассматривается как более важное, и только это отношение моделируется как отношение «один ко многим».
Теперь сделайте еще один шаг. Сети. Отношения "многие ко многим" между эквивалентными партнерами. Как вы можете смоделировать это, не нарушая границы транзакции в ваших совокупных корнях?
Взгляните на этот широко применимый пример:
У меня есть сеть с узлами. Каждый узел имеет ограниченное количество портов. Один порт может быть подключен только к одному порту на другом узле. Я должен иметь возможность добавлять и удалять соединения между узлами, используя порты.
Интуитивным подходом к этому было бы моделирование узлов как совокупных корней, содержащих порты. Соединения кажутся объектами значений, и один порт может иметь одно соединение. Я мог бы реализовать метод Node.ConnectTo (nodeId, portId), который добавляет соединение (между портом X на узле A и портом Y на узле B) в совокупный корень, узел A. Предпочтительно, я бы вызвал этот метод дважды, один раз на Узел A и один раз на узле B и заверните его в транзакцию. Однако это нарушит границу транзакции, поэтому я решил сохранить его только на узле A.
Чтобы увидеть соединение на узле B на клиенте приложения, потребуется отдельная модель чтения. Но это не проблема, архитектура CQRS предоставляет нам эти возможности. Таким образом, добавление, удаление и просмотр соединений не является проблемой.
Проблема возникает, когда я хочу проверить, свободен ли порт, прежде чем добавлять соединение к порту. Результатом соблюдения границ нашей транзакции является то, что (в модели записи) тот факт, что порт уже подключен, может быть неизвестен совокупному корню, но может быть сохранен в любом другом совокупном корне.
Конечно, вы могли бы доверяйте проверке вашего клиента, продолжайте и добавьте соединение, если это нормально для узла, к которому вы его добавляете, и полагайтесь на процесс, выполняющий проверки согласованности, для выполнения компенсирующих действий для недопустимых соединений. Но это кажется мне большим делом по сравнению с обертыванием транзакции вокруг двух вызовов ConnectTo ...
Это заставило меня подумать, что возможно, мои совокупные корни были выбраны неправильно. И я начал думать об узлах и сетях как о совокупных корнях, где сеть - это совокупность подключений. Преимущество агрегата сети в том, что вы всегда можете проверить добавление или удаление соединений. За исключением случаев, когда новое соединение приведет к объединению двух существующих сетей ... И ваша совокупность может стать большой, что может привести только к одной огромной сети. Это тоже неосуществимо.
Как вы думаете, как это следует смоделировать? Видите ли вы решение, в котором вы уважаете совокупные корни как границы транзакций, вы можете проверять свою сеть и не рискуете хранить всю свою сеть как единый агрегат? Или я прошу здесь все 3 CAP и разве это просто невозможно? - person Jochen; 02.06.2012
Теперь сделайте еще один шаг. Сети. Отношения "многие ко многим" между эквивалентными партнерами. Как вы можете смоделировать это, не нарушая границы транзакции в ваших совокупных корнях?
Взгляните на этот широко применимый пример:
У меня есть сеть с узлами. Каждый узел имеет ограниченное количество портов. Один порт может быть подключен только к одному порту на другом узле. Я должен иметь возможность добавлять и удалять соединения между узлами, используя порты.
Интуитивным подходом к этому было бы моделирование узлов как совокупных корней, содержащих порты. Соединения кажутся объектами значений, и один порт может иметь одно соединение. Я мог бы реализовать метод Node.ConnectTo (nodeId, portId), который добавляет соединение (между портом X на узле A и портом Y на узле B) в совокупный корень, узел A. Предпочтительно, я бы вызвал этот метод дважды, один раз на Узел A и один раз на узле B и заверните его в транзакцию. Однако это нарушит границу транзакции, поэтому я решил сохранить его только на узле A.
Чтобы увидеть соединение на узле B на клиенте приложения, потребуется отдельная модель чтения. Но это не проблема, архитектура CQRS предоставляет нам эти возможности. Таким образом, добавление, удаление и просмотр соединений не является проблемой.
Проблема возникает, когда я хочу проверить, свободен ли порт, прежде чем добавлять соединение к порту. Результатом соблюдения границ нашей транзакции является то, что (в модели записи) тот факт, что порт уже подключен, может быть неизвестен совокупному корню, но может быть сохранен в любом другом совокупном корне.
Конечно, вы могли бы доверяйте проверке вашего клиента, продолжайте и добавьте соединение, если это нормально для узла, к которому вы его добавляете, и полагайтесь на процесс, выполняющий проверки согласованности, для выполнения компенсирующих действий для недопустимых соединений. Но это кажется мне большим делом по сравнению с обертыванием транзакции вокруг двух вызовов ConnectTo ...
Это заставило меня подумать, что возможно, мои совокупные корни были выбраны неправильно. И я начал думать об узлах и сетях как о совокупных корнях, где сеть - это совокупность подключений. Преимущество агрегата сети в том, что вы всегда можете проверить добавление или удаление соединений. За исключением случаев, когда новое соединение приведет к объединению двух существующих сетей ... И ваша совокупность может стать большой, что может привести только к одной огромной сети. Это тоже неосуществимо.
Как вы думаете, как это следует смоделировать? Видите ли вы решение, в котором вы уважаете совокупные корни как границы транзакций, вы можете проверять свою сеть и не рискуете хранить всю свою сеть как единый агрегат? Или я прошу здесь все 3 CAP и разве это просто невозможно? - person Jochen; 02.06.2012
Перед выполнением метода ConnectTo на узле A вы проверяете, свободен ли порт на узле B, используя в конечном итоге согласованную модель представления в качестве источника данных (а не модель домена, которая не может эффективно проверить это, см. Выше).
- ConnectTo запускается только на узле A, поэтому границы транзакции не нарушаются.
- Если модель представления не может подключить порт на узле B, потому что он уже используется, произошло истинное исключение параллелизма, и о нем необходимо сообщить. Необходимо предпринять какие-то действия (либо вмешательство вручную, либо автоматический процесс). Вероятность этого исключения параллелизма обычно очень низкая.
- вам нужно сделать ваш вопрос более читаемым
person
Jochen
schedule
26.11.2011
