Как содержательно задокументировать дизайн актера
Я новичок в системах акка / актера и пытаюсь понять код, написанный моим коллегой.
При этом я спрашиваю себя, какая документация была бы полезна для более быстрого понимания реализованной «системы акторов» .
Насколько я понимаю, вам нужно понимать как минимум две разные точки зрения на системы, чтобы понять это.
- Первый - это статическая «иерархия создания», которая в основном определяет отношения между дочерними и родительскими объектами.
- Второй - это динамический «поток сообщений / событий», который в основном определяет сообщения, которыми обмениваются участники. В качестве особого случая сюда также относятся реализованные конечные автоматы.
Итак, мне интересно, есть ли общие передовые методы документирования системы акторов:
- Какие взгляды следует документировать?
- Есть ли рекомендуемые способы структурирования кода (например, отражение родительско-дочерних отношений в виде структуры пакета)?
- Соглашения об именах?
- Инструменты, которые могут анализировать код и предоставлять некоторую документацию?
- ...
Ответы 1
Поскольку я еще не могу комментировать, я бы, по крайней мере, хотел бы указать вам на Акка-Виз в целях визуализации.
Я также недавно задавался вопросом о структуре пакета ... и следует ли каким-то образом изображать иерархию акторов таким образом. Затем я применил представление DDD, в котором акторы - это не что иное, как службы, действующие на сущности. Это не делает упор на деталь реализации акка при попытке понять, что делает приложение. Последнее - это то, что структура пакета должна позволять людям делать.
Также был бы заинтересован в лучшей практике, хотя, если она есть :)