Объектно-ориентированный дизайн и как его использовать для проектирования систем

Спасибо, что обратили внимание. Убрал дубль

Объектно-ориентированный дизайн и как его использовать для проектирования систем

ООД не преследует цель сделать логическую схему БД на стартовом этапе проектирования. Все примеры которые вы приводите — разумные и важные для логической схемы БД, но для нужд ООД ими можно пренебречь (по моему опыту). На данном этапе нам не важно от чего зависит цена — главное, что цена есть как параметр объекта. Не важно от чего зависит скидка — главное, что эта скидка есть. Аналогичного живого примера с моего проекта нет (пример с вакансией с живого проекта), но я бы сделал так, как написал: есть «Заказ» и его цена и есть ассоциированный объект «Товар» с его ценой. В товар также можно положить «Скидку» как напоминание, что есть зависимое значение. А от чего именно — это уже вопрос следующих этапов (хотя ты все равно про это думаешь при формирование этой самой карты объектов)

Объектно-ориентированный дизайн и как его использовать для проектирования систем

Это уже свойства товара: сколько он стоит, какая скидка и тд. В нашем случае «Товар» будет просто отдним из параметров заказа. Товаров в заказе может быть уже много. Как и «Технологий» в случае с вакансией из статьи

Объектно-ориентированный дизайн и как его использовать для проектирования систем

В реальных проектах для скорости (и создания и поддержки) делаем все это в mindmap. Про строку заказа не совсем понял вопрос. Что касается заказа, то он не сильно отличается по логике описания с вакансией: у него также есть номер, дата создания, пользователь, стоимость и так далее. Связан он может быть ассоциацией с другими заказами, товарами (и любыми другими, кто контекстно уместно для вашего конкретного продукта. Если фантазировать, то если это, например, билет на концепт, то это может быть парковка, доп услуги к заказу или расписание концерта). Надеюсь, что все верно понял и подходяще ответил) Если что — дополню