Что ты модель и когда?(Моделирование предприятий, приложений и баз данных)

Question

Представьте, что вы разрабатываете веб-приложение, которое может вырасти до масштабов Amazon или Google.В начале вы начинаете с одного небольшого аспекта проекта, зная, что во имя гибкой разработки вам нужно с чего-то начинать.Например, вы можете создать простой каталог книг, надеясь, что ваш проект сработает, и когда-нибудь вы станете не просто каталогом, а универсальным сайтом для покупки и продажи книг, а также всех других товаров.(Это все чисто гипотетически.)

Какие типы моделирования вы бы использовали?Какие разные "сущности" вы бы смоделировали в начале?Насколько важно, на ваш взгляд, моделирование и какую информацию вы должны использовать, чтобы определить, когда и что моделировать?

В ответе на ранее заданный вопрос о SO имеется ссылка на «ориентированный на данные взгляд на мир» по сравнению с«процессно-ориентированное мировоззрение».Моделируете ли вы поток информации через приложение или веб-сайт (ы) перед тем, как начать выполнять логическое моделирование данных и физическое моделирование данных?Или эти фразы относятся к чему-то другому?

Какие инструменты вы могли бы использовать для моделирования различных типов информации?

Answer 1

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

То есть, когда речь заходит о моделировании.

Конечно, вы должны думать о том, что произойдет, если ваша компания будет расти, но не с точки зрения возможностей, а только с точки зрения производительности.Будет ли ваше приложение работать, если у вас в 10 раз больше посетителей, в 10 раз больше товаров, в 10 раз больше заказов ... Это то, о чем вам нужно беспокоиться, а не о том, что вы собираетесь создать через 2 года.Невозможно предвидеть все, и все попытки написать «умный» и «расширяемый» код приведут к созданию более сложной системы, которую будет сложнее настроить за два года, чем это было бы, если бы вы не думали оэто вообще.

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

Answer 2

Проверка моделей в будущем отличается от проверки реализаций в будущем.

Вот некоторые модели, которые я использовал.

Data models:
    Analysis model (conceptual):  Entity-Relationship modeling
    Design model (logical):  Relational Data Model
    Implementation model (physical):  DBMS specific model

Application models:
    Object Model:  governs messaging among component objects.
    Dynamic Model:  governs states, events, and transitions within an object.
    Functional Model:  governs transformations and computations.

Модели важны для того, что они исключают, так какну и за то, что они оставляют. Не пытайтесь предвидеть все, но и не загоняйте себя в угол.Учитесь на опыте других, затем учитесь на собственном опыте.

Answer 3

По моему опыту, начинание с правильной, сильно нормализованной конструкции БД является ключом к расширяемости в будущем. Чем более атомарно вы можете сделать свои сущности, тем легче будет расширяться ваша система, когда возникнут неизвестные «будущие потребности». Существует разница между планированием заранее того, что вы ЗНАЕТЕ, что будете добавлять, но на данный момент не можете этого сделать из-за нехватки времени или, возможно, (ТОЛЬКО возможно) аппаратных ограничений известной длительности. Но это отличается от планирования «Что если мы станем Google II».

На внутренней стороне - прочная, сильно нормализованная структура стола. На лицевой стороне чистые, слабо связанные классы и дизайн n-Tier имеют большое значение для расширяемости.