Aufrufe
vor 3 Jahren

02 | 2011 NEWS

  • Text
  • Daten
  • Experten
  • Innovationen
  • Analyse
  • Security
  • Management
  • Erfolgreich
  • Internet
  • Banking
  • Technologie
  • Msggillardon
  • Anforderungen
  • Steuerung
  • Banken
  • Kreissparkasse
  • Sculptor
  • Stresstests
  • Basel
  • Marzipan
  • Risiken
Druck von allen Seiten

Application MyApp {

Application MyApp { basePackage=org.helloworld „Facade der Baufinanzierungsbeispielanwendung. „ Module baufifacade { „Externe Service der Baufinanzierungsanwendung.“ Service AntragsService { List sucheAntraege(@AntragFilterDTO filter); // ruft intern das AntragsRepository auf. @Antrag berechneScoring(Long antragsId) => AntragsDomainService.berechneScoring; } „Filterobjekt zur Suche nach Anträgen.“ DataTransferObject AntragFilterDTO { String name String antragsnummer Date antragsDatumVon Date antragsDatumBis } } „Domänenmodell der Baufinanzierungserfassung. „ Module baufi { „Interner Service der Domain.“ Service AntragsDomainService { „Methode, die die Logik mehrerer Domainobjekte kombiniert.“ @Antrag berechneScoring(Long antragsId); } „Basistyp für Geld.“ BasicType Money { BigDecimal value String currency } „Baufinanzierungsantrag.“ Entity Antrag { Long antragsNummer Date antragsDatum - Bag darlehensnehmer - @BeleihungsObjekt objekt // weitere Entitäten wie Darlehensobjekt, Finanzierung, Tilgung etc. Repository AntragRepository { List sucheAntraege(String name, String antragsnummer, Date antragsDatumVon, Date antragsDatumBis); } } „Stellt das zu beleihende Objekt dar.“ Entity BeleihungsObjekt { // ... Attribute ... -- hier uninteressant „Businessmethode, die nur Daten des Beleihungsobjekts sowie Konfigurationsparameter benötigt.“ def @Money berechneBeleihungswert(); } „Darlehensnehmer, der den Baufinanzierungsantrag stellt.“ Entity Darlehensnehmer { not aggregateRoot String vorname String nachname String strasse String plz String ort Date geburtsDatum def int alter; def aendereAdresse(String strasse, String plz, String ort); „Methode zur Berechnung des verfügbaren Einkommens des Darlehensnehmers.“ def @Money berechneEinkommen(); - @EinkommenNichtSelbstaendig einkommenNichtSelb - Bag vermoegenswerte „Beispiel fuer Hibernate Anweisungen im Modell.“ - Bag verbindlichkeiten cascade=“all-delete-orphan“ fetch=“eager“ } „Valueobjekt zur Speicherung von nicht selbständigem Einkommen.“ ValueObject EinkommenNichtSelbstaendig { - @Money einkommen String arbeitgeber } „Valueobjekt zur Speicherung von Vermögen.“ ValueObject Vermoegen { - @Vermoegensart art - @Money betrag } „Valueobjekt zur Speicherung von Verbindlichkeiten.“ ValueObject Verbindlichkeit { - @Verbindlichkeitart art - @Money betrag } enum Vermoegensart { IMMOBILIE, BAUSPARVERTRAG, SONSTIGES } enum Verbindlichkeitart { KLEINKREDIT, SONSTIGES } } } Listing 1: Baufinanzierungsmodell beschrieben mit Sculptor DSL 44 I NEWS 02/2011

Business t Informationstechnologie t nehmers können somit als Value Objects modelliert werden. Ein Vermögensbetrag hat keine eigene Identität, sondern besteht im Wesentlichen aus einer Vermögensart und dem Geldbetrag, der eventuell mit Währung abgespeichert werden soll, und ist untrennbar mit seinem Entity-Darlehensnehmer verbunden. Ein Basic Type schließlich entspricht einem JPA Embeddable Object und kann als Attribut einer Entity oder eines Value Objects Teil des Domain-Models sein. Beispiele hierfür sind fachliche Datentypen wie Geldbeträge, rabattierbare Beträge oder Beträge, deren Steuern mit ausgewiesen werden müssen. Für den Geldbetrag im Value-Object-Vermögen würde sich demnach ein Basic Type Money anbieten. Werden nun Objekte miteinander über Relationen verbunden, ergibt sich ein Aggregate, das über ein Aggregate Root Entity (Wurzelobjekt) von außen zugreifbar ist. Referenzen sind von Root auf Unterknoten und Unterknoten untereinander möglich, von außen nur auf das Root-Objekt. Im Beispiel ist das Antragsobjekt die Klammer um die Daten einer Baufinanzierung und somit das (eventuell einzige) Aggregate Root. Soll auch auf Darlehensnehmer unabhängig von Anträgen zugegriffen werden, z. B. im Rahmen einer Kundensuche, dann sollte auch der Darlehensnehmer als Aggregate Root modelliert werden. Den Zugriff auf die Domain-Objekte regelt das Repository. Es kümmert sich um das Persistieren sowie das Löschen von Domain-Objekten und kapselt somit die Logik des Datenbankzugriffs ab. Im Unterschied zum DAO (Data Access Object) befindet sich das Repository auf einer höheren Abstraktionsstufe. Während ein DAO pro Tabelle existiert, schottet ein Repository ein Aggregate nach außen ab. Folglich können Repositories in Sculptor auch nur auf den Aggregate-Root-Objekten definiert werden. Die Businesslogik der Anwendung schließlich wird durch einen Service Layer um das Domain-Model herum veröffentlicht (Application Services). Ein Service stellt somit eine wohldefinierte Schnittstelle mit einer Menge von Operationen dar, die von einem Client aus zugreifbar sind. Der Service Layer orchestriert dabei Abbildung 1: Überblick DDD-Artefakte, © Eric Evans 2004 die Businesslogik aus den Domain-Objekten (Domain Services), die wiederum neben der Logik auf den eigenen Daten auch die Logik der abhängigen Domain-Objekte aufrufen können. Sculptor unterstützt Domain-Services nicht direkt. Im Beispiel wurde daher ein zweites Modul definiert, um den Unterschied deutlich zu machen. Während in der baufifacade die Application Services definiert sind, werden im baufi-Modul die Domain-Services nach außen verfügbar gemacht. Der Client spricht nur mit der baufifacade, die wiederum auf mehrere Domänen zugreifen könnte. Es würde sich auch anbieten, die Facade mittels des Sculptor-DSL-Schlüsselworts webserviceexternen Clients als Webservice anzubieten. Module oder Packages stellen schließlich eine Methode dar, um miteinander verwandte Konzepte und Aufgaben zu organisieren und Komplexität zu reduzieren. Die Schnittstellen zwischen den Modulen sollen dabei wohldefiniert und die Kommunikation zwischen den Systemen soll explizit implementiert sein. Module sollten auf getrennten Datenbereichen arbeiten, d. h. wenn gemeinsame Daten vorhanden sind, ist entweder ein gemeinsames Modul zu bilden oder eine entsprechende Schnittstelle auf Service Level vorzusehen. Eine Übersicht über die Artefakte von Domain Driven Design ist in Abbildung 1 dargestellt. NEWS 02/2011 I 45

msg

01 | 2018 public
02 | 2017 public
01 | 2017 public
02 | 2016 public
01 | 2016 public
02 | 2015 public
01 | 2015 public
01 | 2014 public
01 | 2014 msg systems study
01 | 2015 msg systems Studienband
Future Utility 2030
Lünendonk® Trendstudie
Digitale Transformation | DE
Digital Transformation | EN
DE | inscom 2014 Report
EN | inscom 2014 Report

msgGillardon

02 | 2018 NEWS
03 | 2016 NEWS
02 | 2016 NEWS
01 | 2016 NEWS
03 | 2015 NEWS
02 | 2015 NEWS
01 | 2015 NEWS
02 | 2014 NEWS
01 | 2014 NEWS
02 | 2013 NEWS
01 | 2012 NEWS
02 | 2011 NEWS
01 | 2010 NEWS
MaRisk
01 | 2017 banking insight
01 | 2015 banking insight
01 | 2014 banking insight
01 | 2013 banking insight
01 | 2012 banking insight
02 | 2011 banking insight
01 | 2011 banking insight
01 | 2010 banking insight
2018 | Seminarkatalog | Finanzen

Über msg



msg ist eine unabhängige, international agierende Unternehmensgruppe mit weltweit mehr als 6.000 Mitarbeitern. Sie bietet ein ganzheitliches Leistungsspektrum aus einfallsreicher strategischer Beratung und intelligenten, nachhaltig wertschöpfenden IT-Lösungen für die Branchen Automotive, Banking, Food, Insurance, Life Science & Healthcare, Public Sector, Telecommunications, Travel & Logistics sowie Utilities und hat in über 35 Jahren einen ausgezeichneten Ruf als Branchenspezialist erworben.

Die Bandbreite unterschiedlicher Branchen- und Themenschwerpunkte decken im Unternehmensverbund eigenständige Gesellschaften ab: Dabei bildet die msg systems ag den zentralen Kern der Unternehmensgruppe und arbeitet mit den Gesellschaften fachlich und organisatorisch eng zusammen. So werden die Kompetenzen, Erfahrungen und das Know-how aller Mitglieder zu einem ganzheitlichen Lösungsportfolio mit messbarem Mehrwert für die Kunden gebündelt. msg nimmt im Ranking der IT-Beratungs- und Systemintegrationsunternehmen in Deutschland Platz 7 ein.


© 2018 by msg systems ag - powered by yumpu Datenschutz | Impressum