Комментарии 13
А можно побольше реальных примеров? Как например оформить составные объекты (заказ и строка заказа)? Каким образом описывается взаимодействие? Какие инструменты используете, чтобы быстро рисовать и изменять эти карточки?
Внутри заказа есть строки — какой товар, в каком кол-ве, по какой цене и с какой скидкой и налогами. Строка заказа не может существовать отдельно от заказа.
Цена да, но скидка (и налоги) в каждом заказе на каждый отдельный товар может быть разная. Поэтому ее нельзя хранить в товаре.
В общем суть в чем — на простых учебных материалах все эти методики выглядят отлично, но когда дело касается реальной более менее сложной предметной области — все летит к чертям. Вот и вопрос — есть примеры описания сложных составных сущностей? И как это выглядит?
Технология — это поле (в ui — выпадающий список из справочника), а строки заказа — это вложенный список других объектов. И не просто объектов, а с доп. полями, которые нельзя хранить объекте товара (скидка).
Можно посмотреть на книжку Эванса про DDD — там как раз рассматриваются агрегаты.
Я ищу способ хорошо организованной документации по проекту и по бизнес-процессам. От простого к сложному или взгляд с разных сторон (как 4+1 в архитектуре). Чтобы пришел программист и сразу все нашел и понял, и не пришлось бы перечитывать тонну доков, прежде чем сделать задачу. То, что описано в статье — мне показалось хорошей базой для этого. Описания объектов по крайней мере простые и лаконичные. Как-то я видел описания юзер-сторей, которые ложились на код один-к-одному, даже папочки в коде в IDE были в соответствии с ними.
Если б я видел какие-то такие организованные системы документации, я б сказал с уверенностью. Самое навороченное, что я видел был RUP, но это было сто лет назад и не знаю, чем там дело кончилось с ним. Есть какой-то Open UP эклипсовски.
На практике, я вижу инкрементность документации — т.е. кто-то описывает текущий инкремент, а потом он устаревает и через год надо ходить по истории и собирать эти икременты и применять их друг к другу, чтобы получить целостное представление.
В результате практичный способ оказывается конгломератом из кода, тестов, тасок и мозгов сотрудников которые дополняются только основными концепциями написанными в вики (потому, что основные концепции меняются редко и их не в лом поддерживать).
Детальное проектирование проще держать в коде и тестах.
Если у кого-то есть другой опыт, я бы с удовольствием про него почитал.
...
Ещё можно почитать по теме конспект воркшопа Глеба Кушедова по методологии OOUX.
Объектно-ориентированный дизайн и как его использовать для проектирования систем