Ist das Modellieren eines Datenbankmodells ein guter Ansatz zum Entwerfen komplexer und großer Unternehmensanwendungen?

Question

Wir arbeiten an einer ausgefuchsten, großen, serviceorientierten, mehrschichtigen Anwendung, die von Grund auf neu entwickelt werden muss. Nun müssen wir mit der Programmierung beginnen und versuchen, die ersten Bausteine ​​zusammenzusetzen.

Die Frage ist, wo ich anfangen soll? Einige schlagen vor, dass wir mit dem Entwurf der persistenten Datenmodelle beginnen sollten, die eine klarere Sicht bieten würden. Ist das ein guter Ansatz?

Edit für Suirtimed

gibt es nicht viel ein Agile Kultur hier. Dies ist ein SOA-Projekt, das WCF, SQL Server, Entity Framework (mithilfe von POCO-Generator für Domänenobjekte), ASP MVC und Workflow Foundation verwendet. Wir sind ein Team von 4 Entwicklern; einigermaßen erfahren (aber keine Experten).

Answer 1

Der allgemeine Ansatz, dem ich immer zu folgen versuche, besteht darin, zunächst die Domänenmodelle zu entwerfen. Dies ist Ihre "allgegenwärtige Sprache", die Geschäftsobjekte und Konzepte definiert, Geschäftslogik enthält (später, wenn Sie sie haben) und allgemein die allgemeine Sprache ist, die in den verschiedenen Teilen des Systems verwendet wird.

Die Idee ist, dass es von allen Beteiligten verstanden (oder zumindest verständlich) sein sollte. Zum Beispiel wird ein Manager in einer anderen Abteilung nicht unbedingt relationale Datenbanken verstehen oder etwas über das Fortbestehen der Daten seiner Abteilung darin. Aber er versteht den Geschäftsprozess seiner Abteilung. Ihre Muttersprache, ihre Konzepte, ihre Interaktionen usw. Die allgegenwärtige Sprache ist der gemeinsame Nenner, den die Gruppen teilen.

Während dieses Prozesses sollten Sie Ihre Abhängigkeiten in den Vordergrund stellen. Der größte ist in der Regel Datenpersistenz. Es gibt eine Art goldenen Traum, dass Domänenmodelle Persistenz - ignorant oder Abhängigkeit - ignorant im Allgemeinen sind, und zum Zweck der Trennung von Bedenken ist das eine gute Sache. Wahre Abhängigkeit Ignoranz kann dich jedoch in eine Ecke ziehen. Es kann zu ernsthaften Leistungsproblemen oder Architekturproblemen kommen, die später viel Neuentwurf erfordern.

Also brechen Sie gelegentlich von der Domänenmodellierung ab, um über die Persistenz (und andere externe Abhängigkeiten wie externe Dienste, die verwendet werden müssen, oder Anwendungen von Drittanbietern, die integriert werden müssen) nachzudenken. Stellen Sie beim Modellieren der Domäne sicher, dass das Modell immer noch mit allen erforderlichen Funktionen ordnungsgemäß funktioniert. Möglicherweise müssen Sie hier und da ein wenig an der allgegenwärtigen Sprache Abstriche machen, um den Beschränkungen einer Abhängigkeit Rechnung zu tragen.

Entwerfen Sie im Grunde das Domänenmodell, bevor Sie die Datenbank entwerfen. Aber vergessen Sie nicht die Datenbank während dieses Prozesses.

Answer 2

Wenn Sie komplett von Grund auf neu entwerfen, dann haben Sie den Vorteil, zu definieren, wie Ihre Daten aussehen werden.

Alles, was ich sagen kann, ist aus meiner Erfahrung, dass es hilfreich ist, so viel wie möglich von der Datenstruktur/Geschäftslogik zu bekommen.

Je tiefer Sie in Ihre Anwendung kommen, desto schwieriger wird es, alles neu zu justieren, wenn sich die Daten ändern müssen - und die Daten ändern sich, egal wie viel Sie vorbereiten, Sie müssen diese Änderungen nur minimieren.

Ich persönlich würde sagen, ja, so viel von der Daten-Design aus dem Weg wie möglich zu bekommen. Du kannst den Wagen nicht vor das Pferd stellen.

Answer 3

Wir beginnen normalerweise mit einigen Anwendungsfällen, um einige der verwendeten Entitäten zum Speichern von Daten zu initialisieren. Danach versuchen wir, einige Datenbankmodelle zu erstellen und suchen insbesondere nach der Beziehung zwischen den Entitäten.

Wenn das Basis-DB-Modell existiert, werden wir einen Prototyp entwickeln und versuchen, möglichst viele Anwendungsfälle in den Prototyp aufzunehmen.

Answer 4

Da die Datenbank das Schlüsselelement ist, das die Unternehmensanwendung zusammenfügt, ist es eine gute Idee, damit zuerst zu beginnen oder es zumindest simultan mit den Anwendungsentwürfen zu tun. Verlassen Sie sich nicht auf die Anwendung, wie die Datenbank strukturiert sein sollte. Sie müssen auf Datenintegrität, Leistung und Sicherheit, nicht auf Objektorientierung achten! Beginnen Sie mit einem Datenbankentwurf, der mindestens der 3. Normalform entspricht.

Der Entwurf des Datenmodells ist entscheidend für die Leistung und Datenintegrität. Und es ist die schwierigere Sache, später neu zu entwerfen. Darüber hinaus werden Sie für ein Enterprise-Produkt einige Dinge benötigen, die nur in der Datenbank vorhanden sind, wie etwa die Aufzeichnungsprüfung, die von Anfang an entworfen werden sollte. Wahrscheinlich werden Sie wissen wollen, wer Änderungen an den Datensätzen vorgenommen hat, was die Änderung war und aus welcher Anwendung sie stammt. Dies wird enorm dazu beitragen, fehlerhafte Datenänderungen rückgängig zu machen und festzustellen, welche Anwendung ein Problem verursacht hat, das zu schlechten Änderungen geführt hat.