newseasonhw2015 Hier klicken mrp_family lagercrantz Cloud Drive Photos Professionelle Fotografie2 Learn More praktisch Siemens Shop Kindle Shop Kindle Autorip SummerSale

Kundenrezensionen

9
4,1 von 5 Sternen
Ihre Bewertung(Löschen)Ihre Bewertung


Derzeit tritt ein Problem beim Filtern der Rezensionen auf. Bitte versuchen Sie es später noch einmal.

28 von 29 Kunden fanden die folgende Rezension hilfreich.
am 11. Februar 2007
Es gibt viele Bücher, die von Objektorientierung schreiben, hier aber ist das erste, das sich dem Kern der OO widmet. Dies ist kein Technikbuch, es werden keine Hypes beschrieben - dieses Buch hätte so schon fünfzehn Jahre früher geschrieben werden können: Es geht "einfach" darum, die Fachlichkeit 1:1 in einem Software-Modell - dem Domain-Model - abzubilden.

Das Thema ist nicht leicht, nicht umsonst hat sich bisher kein Autor an das Thema gewagt. Doch dem Autor gelingt es, dass der Leser das echte OO-Gefühl entwickeln kann.

Hier mein Lob:

- Der Autor hat den Mut, sich gegen weitverbreitete Irrtümer zu stellen (z.B. in der Kritik, Systeme nach technischen Gesichtspunkten in Pakete zu unterteilen).

- Er nutzt gute Beispiele: Nicht trivial, um den Vorteil des Domain-Driven-Design aufzuzeigen. Aber auch nicht zu komplex, sie sind jederzeit ad hoc zu verstehen.

- Er spricht explizit Fehler an, die er auch selbst gemacht hat.

Nun zu meinem Tadel:

- Er nutzt einen zu blumigen Stil, wiederholt sich oft. Das Gleiche hätte man auch mit ein Drittel an Seiten sagen können.
0KommentarWar diese Rezension für Sie hilfreich?JaNeinSenden von Feedback...
Vielen Dank für Ihr Feedback.
Wir konnten Ihre Stimmabgabe leider nicht speichern. Bitte versuchen Sie es später noch einmal.
Missbrauch melden
5 von 5 Kunden fanden die folgende Rezension hilfreich.
am 13. Dezember 2007
Dieses Buch gehört für mich zu den "Klassikern" - weil Evans als erster Autor die Kluft zwischen Analyse und Architektur/Implementierung mal gründlich und systematisch bearbeitet!

Seine "Building Blocks of Domain Driven Design" (Entities, Services, Repositories, Factories etc.) zeigen endlich mal einen systematischen Weg von fachlichen zu technischen Klassenmodellen auf - sehr lesenswert!

Leider fällt der zweite Teil des Buches doch sehr ab - da wird der Stoff anekdotenhaft und teilweise zusammenhanglos. Diese Hälfte hätte Evans besser schreiben können (da springt dann Jimmy Nilson mit seinen DDD-Patterns in die Bresche!)

Meine Bewertung bezieht sich NUR auf die erste Hälfte des Buches - die bekommt "MaxNrOfPoints".

Fazit und vergleichbare Bücher: Die frei verfügbare Kurzfassung von A. Avram von infoQ ist ein allzu stark gekürzter Abklatsch der (faszinierenden) Thematik - aber zum ersten Einstieg reicht es sicherlich aus. Wer modelliert, sollte das Original lesen.

Wie gesagt - Jimmy Nilson und seine DDD-Patterns, die sind auch für nicht-.NET'ler gut verständlich.
0KommentarWar diese Rezension für Sie hilfreich?JaNeinSenden von Feedback...
Vielen Dank für Ihr Feedback.
Wir konnten Ihre Stimmabgabe leider nicht speichern. Bitte versuchen Sie es später noch einmal.
Missbrauch melden
18 von 20 Kunden fanden die folgende Rezension hilfreich.
am 3. März 2004
Das Buch beschäftigt sich mit der fachlichen Modellierung objektorientierter Systeme und der Autor vertritt deutlich die Ansicht, dass der Systemkern durch die fachlichen Modelle getrieben sein soll. Damit die fachliche Modellierung gelingt, ist eine gemeinsame und eindeutige Sprache der Projektbeteiligten von Nöten.
Dieser generelle Ansatz wird dann ausgearbeitet, indem die Bausteine für fachliche Modellierung in Pattern-Form präsentiert werden. Durch die Pattern-Form ist selektives Lesen möglich.
Im Buch werden immer mal wieder Bezüge zu agilen Vorgehensweisen hergestellt. Das Buch dürfte aber genausogut in nicht-agilen Projekten funktionieren.
Das Buch hat für jede Könnensstufe etwas zu bieten und schließt eine ganz deutliche Lücke in der Literaturlandschaft.
0KommentarWar diese Rezension für Sie hilfreich?JaNeinSenden von Feedback...
Vielen Dank für Ihr Feedback.
Wir konnten Ihre Stimmabgabe leider nicht speichern. Bitte versuchen Sie es später noch einmal.
Missbrauch melden
23 von 27 Kunden fanden die folgende Rezension hilfreich.
am 14. November 2003
Metapher war die wohl am stärksten unterdokumentierte XP-Technik. Nun gibts ein ganzes Buch dazu: Eric Evans beschreibt, wie ein XP-Team sein gemeinsames Vokabular findet, daraus ein mächtiges Domänenmodell entwickelt und dann beide eng miteinander verzahnt einem fortwährenden Refactoring unterwirft. Das Ziel: Die Sprache im Team (Kunden miteingeschlossen), als auch Code und Design werden zunehmend ausdruckskräftiger, die Komplexität sinkt und Anforderungen werden leichter kommunizierbar und testbar.
Teilweise wirkt mir das Buch etwas langatmig, da in Patterns-Form à la Christopher Alexander aufgeschrieben. Trotzdem für mich das Buch des Jahres. Mit Hang zum Klassiker.
0KommentarWar diese Rezension für Sie hilfreich?JaNeinSenden von Feedback...
Vielen Dank für Ihr Feedback.
Wir konnten Ihre Stimmabgabe leider nicht speichern. Bitte versuchen Sie es später noch einmal.
Missbrauch melden
1 von 1 Kunden fanden die folgende Rezension hilfreich.
am 26. Mai 2015
Der Titel könnte in die Irre führen. Das Buch befasst sich ausschließlich mit der Modellierung der Anwendungsdomäne. Unter "Design" wird anderswo der gesamte Entwurf einer Anwendung verstanden, also auch der Benutzerschnittstelle, Datenzugriffe, sonstige technische Schichten, Kommunikation, Schnittstellen. Darum geht es hier nicht, sondern ausschließlich um die Erstellung eines Modells der Anwendungsschicht. Das spricht nicht gegen das Buch, aber man sollte seine Erwartungen entsprechend justieren.

Das Buch hat vier Teile. Etwa bis zur Mitte des dritten Teils geht es gemächlich voran, mit viel Wiederholungen, eingehender Diskussion auch kleiner Entwicklungsschritte. Trotzdem hatte ich den Eindruck, dass er sich schwer tut, das Thema wirklich lehrend zu vermitteln. Die Grundbotschaft ist klar und gut: Es lohnt, sich eingehend mit dem Domänenmodell zu befassen, es immer wieder in Frage zu stellen und an den gewonnenen Kenntnisstand anzupassen. Aber wenn ich beim nächsten Modell, das ich erstellen soll, versuchen wollte, mein Handeln an der Botschaft des Buchs auszurichten, würde ich mich schwer tun. Vielleicht ist es auch inhärent schwierig, gute fachliche Modelle zu machen, und man kann nur an Einzelbeispielen lernen und versuchen, die eigenen Schlüsse daraus zu ziehen.

Das ist dem Autor vermutlich bewusst, und er kreist in dieser ersten Hälfte immer wieder um die gleichen Konzepte, vermutlich, um sie uns eindrücklich zu vermitteln. Die Notation seiner "Patterns" (der Begriff ist für das, was er darstellt, weit hergeholt, aber er muss wohl mit den Pattern-Wölfen heulen) in Kapitälchen tut das ihre, den Eindruck des Einhämmerns der Kernbotschaft, etwa von der Ubiquitous Language zu vestärken.

Etliche seiner Entwurfsideen finde ich fragwürdig oder unzureichend begründet, etwa:

- Die Darstellung der Richtung von Assoziationen schon während der fachlichen Modellierung. Meist kennt man in einem frühen Stadium noch nicht alle funktionalen Anforderungen und könnte meinen, dass eine Assoziation nur in einer Richtung navigiert werden muss. Meist kommt der Wunsch nach der anderen Richtung später hinzu. Deswegen verwenden wir doch Datenbanken, um nicht nur vom Auftrag kommend den Kunden, sondern auch vom Kunden alle Aufträge zu finden. Wenn man sich bei der Architektur auf die Einbahnrichtung verlassen hat, steht man jetzt im Regen. Wenn es hinterher problemlos zu ändern ist, hätte man sich die Einbahnrichtung von vornherein sparen können.

- Die Empfehlung, bei Entities nur wenige identifizierende Attribute zu belassen und alle anderen in Value Objects auszulagern. Das führt zu unnötig vielen Modellobjekten, und er gibt keinen Vorteil an, der das rechtfertigt.

Der Eindruck des langsamen Fortschritts beim Lesen kommt auch daher, dass manchmal ein offensichtlich unzureichendes Design an den Anfang gestellt und dann mit viel Erklärungen verbessert wird. Mein Lieblingsbeispiel ist das Modell auf S. 164. Da gibt es eine Klasse DeliveryHistory. Als ich die sah, fragte ich mich: Warum führt er die ein, sie kann doch nur die HandlingEvents enthalten, die ohnehin schon mit der Cargo verbunden sind? Und siehe da, auf S. 178 kommt er auf die Idee, die DeliveryHistory brauche man gar nicht, weil man sie durch Datenbankabfragen ersetzen kann.

Ein anderes Beispiel: Das Farbmischungsproblem, das er im dritten Teil extensiv heranzieht. Auf S. 259 ist mir der Kragen geplatzt, als immer noch eine zu umständliche Struktur übrigblieb. Viel einfacher wäre folgende Lösungsstruktur:

(a) ermittle aus der zu bemalenden Fläche das Farb-Gesamtvolumen absolut
(b) kollateral zu (a) ermittle aus der Wunschfarbe das Mischungsverhältnis der Elementarfarben relativ
(c) ermittle aus beiden Ergebnissen die Menge der Elementarfarben absolut.

Der gewichtigste Kritikpunkt aus meiner Sicht ist die Annahme, man könne alle Projektbeteiligten dazu bringen, die Ubiquitous Language, also eine präzise Modellsprache aller fachlichen Begriffe, zu verwenden. Für Analytiker und, mit viel Geduld und gutem Willen, für Entwickler, mag das durchsetzbar sein, vor allem, wenn die Entwickler räumlich und kulturell nahe bei den Analytikern sind. Aber den möglichen Einwand, die Anwender, mit denen wir ihre Anforderungen diskutieren, könnten zu dieser Stringenz nicht in der Lage sein, tut der Autor mit einem Satz ab: "... a domain expert is assumed to be capable of thinking somewhat deeply about his or her field" (S. 33). Was ist in der Praxis ein domain expert? Meine letzten domain experts waren vier Lagermanager. Die sind Experten für vieles, u.a. dafür, einfach gestrickte Lagermitarbeiter richtig einzusetzen und zu effizientem und verlässlichen Handeln anzuleiten. Oder dafür, einem Vorstand zu erklären, dass die Beschaffung einer neuen Regaltechnik sich auch bei knappen Budgets auszahlt. Alle ein, zwei Monate treffen sie sich mit uns - und sollen plötzlich die gleiche Disziplin bei ihrer Kommunikation üben wie etwa ein Physiker? Ich will nicht abstreiten, dass man solche Anwender vorfinden kann, aber eine Methode, die nur unter solch idealen Bedingungen zum Ziel führt, hat keinen großen Anwendungsbereich.

Etwa ab Kapitel 10, und spätestens im vierten Teil, ändert sich das Erzähltempo. Man erkennt das schon an der Dichte der "Muster" im Inhaltsverzeichnis, die dem Leser jetzt um die Ohren gehauen werden. Oft sind die Erläuterungen jetzt recht abstrakt gehalten. Ich hatte den Eindruck: Er hat hier einen ungeheuren Erfahrungsschatz, aber er nimmt sich nicht die Zeit, ihn zu vermitteln. Ein Beispiel von vielen ist der Abschnitt "Unifying an Elephant" ab S. 378. Hier geht es darum, dass unterschiedliche Leute ein und dasselbe Konzept verschieden interpretieren. Das erlebt man in der Praxis dauernd, etwa bei einem Warenbestand. Der Lagermanager interessiert sich für Abmessungen, Bestand und Lagerungsvorschriften der Ware. Der Verkäufer sieht den Preis und den Abverkauf. Der Einkäufer sieht Bezugsquellen, Einkaufspreise und Lieferkonditionen. Trotzdem ist es keine große Schwierigkeit für uns, eine Entität Ware zu definieren, die alle diese Sichten befriedigt. Was an dem Ansatz im Buch besonders sein soll, erschließt sich aus der Darstellung, die weiterhin um den Elefanten kreist, nicht.

Fazit: Es bleibt die Botschaft übrig, sich sorgfältig mit dem Anwendungsmodell zu befassen. Umso rätselhafter, weshalb der Autor, nachdem er ein dickes Buch darüber geschrieben hat, auf S. 446 beklagt: "... little has been published on the structuring of the domain layer. ... This whole area is still undeveloped."
0KommentarWar diese Rezension für Sie hilfreich?JaNeinSenden von Feedback...
Vielen Dank für Ihr Feedback.
Wir konnten Ihre Stimmabgabe leider nicht speichern. Bitte versuchen Sie es später noch einmal.
Missbrauch melden
am 18. Juni 2013
der autor gibt einleuchtende antworten und hinweise, wie man die software entwicklung angeht um erfolgreich zu sein.
manche punkte sind straight forward, es kann jedoch nicht schaden, sie beim namen zu nennen. andere punkte wiederum erschließen sich erst im lauf der zeit.
alles in allem ein 'standardwerk'.
sehr empfehlenswerte lektüre!
0KommentarWar diese Rezension für Sie hilfreich?JaNeinSenden von Feedback...
Vielen Dank für Ihr Feedback.
Wir konnten Ihre Stimmabgabe leider nicht speichern. Bitte versuchen Sie es später noch einmal.
Missbrauch melden
9 von 26 Kunden fanden die folgende Rezension hilfreich.
am 10. November 2011
If you can't sleep, then buy this book. I bought the book on many rave reviews but to me the author is keen to show off his intelligence and ego and write a book about a subject which could quite easily be written about in a few pages.

It is not at all practical and covers a subject in vague context which can quite easily be adopted using the tools available in some of the better development software programs.

Avoid this (expensive) book if you really need to learn how to design a domain model.
11 KommentarWar diese Rezension für Sie hilfreich?JaNeinSenden von Feedback...
Vielen Dank für Ihr Feedback.
Wir konnten Ihre Stimmabgabe leider nicht speichern. Bitte versuchen Sie es später noch einmal.
Missbrauch melden
0 von 6 Kunden fanden die folgende Rezension hilfreich.
am 6. April 2009
Mehr als der Titel bleibt gar nicht mehr zu sagen. Das Buch ist für jeden seriösen, profesionellen Entwickler ein absolutes Muss.
0KommentarWar diese Rezension für Sie hilfreich?JaNeinSenden von Feedback...
Vielen Dank für Ihr Feedback.
Wir konnten Ihre Stimmabgabe leider nicht speichern. Bitte versuchen Sie es später noch einmal.
Missbrauch melden
1 von 35 Kunden fanden die folgende Rezension hilfreich.
am 7. Mai 2004
Dieses Buch darf auf keinen Fall in dem Bücherregal eines aufstrebenden Entwicklers fehlen!
Für mich ist dies ein sehr wertvolles Buch das einen Themenschwerpunkt auf ein sonst sehr wenig behandeltes Thema legt.
0KommentarWar diese Rezension für Sie hilfreich?JaNeinSenden von Feedback...
Vielen Dank für Ihr Feedback.
Wir konnten Ihre Stimmabgabe leider nicht speichern. Bitte versuchen Sie es später noch einmal.
Missbrauch melden
     
 
Kunden, die diesen Artikel angesehen haben, haben auch angesehen

Building Microservices
Building Microservices von Sam Newman
EUR 28,74

 
     

Gesponserte Links

  (Was ist das?)
  -  
Jetzt .software Domain sichern. Ohne Setupkosten. Sofort online.
  -  
Ist Ihre .design-Domain noch frei? Einfach checken, günstig sichern!
  -  
Create 3D Renderings in Seconds. Download KeyShot Now!