Domeingestuurd ontwerp – DDD-programmering

5 minuten lezen
Domeingestuurd ontwerp – DDD-programmering
Afbeelding: Dragoscondrea | Dreamstime
Delen

Naarmate de informatietechnologie vordert en nieuwe software wordt ontwikkeld, zoeken bedrijven steeds meer manieren om relatief snel veilige applicaties en systemen te creëren die aan alle voorwaarden voldoen en die gemakkelijk te testen en te ontwikkelen zijn. Met vallen en opstaan ​​is een aanpak ontstaan ​​die door veel organisaties wordt gezien als de ideale manier om software te bouwen.

Het gaat over Domain Driven Design. Wat is precies deze benadering van softwareontwikkeling in het bedrijf?

Domain Driven Design (afgekorte naam DDD) – wat is deze aanpak?

Helemaal aan het begin is het de moeite waard om te definiëren wat de DDD-aanpak precies is. Het is een manier om applicaties en systemen te bouwen die in principe de behoeften van het bedrijf moeten weerspiegelen – zakelijke aannames die tegelijkertijd voorwaarden worden die in de software worden opgenomen.

Domain Driven Design is een techniek voor softwareontwikkeling die wordt gebruikt in de grootste bedrijfsinformatiesystemen.

Wat zijn de inputs die ten grondslag liggen aan de DDD-methode? Allereerst moet het ontwerp van software gebaseerd zijn op een gelijkwaardige samenwerking tussen programmeurs en mensen die direct gerelateerd zijn aan het bedrijf, die tegelijkertijd de beoogde consument van de oplossing zijn. De tweede voorwaarde voor het maken van systemen met behulp van de DDD-methode is het ontwerp van de projectlogica in de vorm van domeinen.

Domain Driven Design
Afbeelding: Juthamat Yamuangmorn | Dreamstime

Wat is een domein? In een notendop, dit is een specifiek bedrijfsgebied dat moet worden geïmplementeerd. Een gebied dat moet worden verbeterd met nieuw gemaakte of ontwikkelde software. Afhankelijk van het belang en de essentie van een bepaald concept en functionaliteit kunnen we domeinen indelen in:

  • De hoofddomeinen, die het belangrijkste onderdeel van het systeem zijn en verantwoordelijk zijn voor de belangrijkste functionaliteit.
  • Ondersteuningsdomeinen, dit zijn extensies van het hoofddomein – zonder dit zijn ondersteuningsdomeinen waardeloos.
  • Algemene domeinen, die belangrijke maar optionele functies zijn.

Waar bestaat DDD uit?

Het proces van het maken van nieuwe software op basis van de principes van Domain Driven Design verschilt enigszins van de traditionele benadering van softwareontwikkeling, die een aantal technische problemen omvat met betrekking tot de verwerking van mechanica, gegevensinvoer en -uitvoer, communicatie met de server, database en integratie met andere tools die door de organisatie worden gebruikt.

UX-ontwerp – Ontwerp van gebruikerservaring
UX-ontwerp – Ontwerp van gebruikerservaring
4 minuten lezen

DDD-programmering bestaat voornamelijk uit domeinmodellen (root-, sub- en algemene domeinen) die een zeer basale implementatie bevatten van de bedrijfsparameters die in de software moeten worden opgenomen. Het is erg belangrijk dat de programmeur die verantwoordelijk is voor het ontwikkelen van de code, het doel van het maken van nieuwe software grondig begrijpt en de waarde begrijpt die het domein in zich draagt. DDD kan niet zonder een taal te definiëren waarmee domeinexperts en programmeurs die taal gemakkelijk kunnen begrijpen. Voor deze benadering werd deze taal de Alomtegenwoordige taal genoemd.

Welke problemen kunnen zich voordoen bij het gebruik van de Domain Driven Design-aanpak?

Wat is het grootste probleem bij het gebruik van de DDD-methode? Allereerst is het de communicatie tussen de business en de technische kant. Als algemene regel geldt dat er in een DDD-aanpak altijd ruimte moet zijn voor een domeinexpert die diepgaande kennis heeft van de aanpak en op zichzelf zal optreden als een “compiler” in bedrijfs- en IT-communicatie.

Domain Driven Design
Afbeelding: Seventyfourimages | Dreamstime

Vanwege het relatief kleine percentage projecten dat met de DDD-methode is gemaakt, is het erg moeilijk om iemand te vinden die een dergelijke rol met volledige toewijding op zich kan nemen. Het gebrek aan ervaring voor programmeurs bij het maken met behulp van de DDD-methodologie kan ook voor extra problemen zorgen.

Voor- en nadelen van de DDD-aanpak

Laten we beginnen met de voordelen van het gebruik van een Domain Driven Design-aanpak bij het maken van nieuwe software. Allereerst is het een geweldige oplossing voor complexe projecten waar het aantal functies, implementatiedoelen en verschillende niveaus zo groot is dat het moeilijk is om het conceptueel vast te leggen in een traditioneel applicatieontwerp. De DDD-aanpak komt tegemoet aan de reële behoeften van de business – er is geen ruimte voor halve maatregelen – als het domein door de programmeur correct wordt geïnterpreteerd, zal het volledig in overeenstemming met de behoeften van de eindgebruiker worden geïmplementeerd. Het is ook vermeldenswaard de relatief lage kosten van het ontwikkelen van de applicatie, die vanaf het begin is gemaakt in overeenstemming met de DDD-aanpak.

Infographics – de kunst van het presenteren van informatie
Infographics – de kunst van het presenteren van informatie
6 minuten lezen

Wat zijn de nadelen van het gebruik van deze techniek? Het grootste nadeel is weinig oefening in het gebruik van deze manier om nieuwe software te ontwikkelen. Hierdoor brengt het starten van een nieuwe strategie, vanuit het oogpunt van het projectteam, het risico met zich mee van een volledig verkeerd begrip van het concept en, als gevolg daarvan, mislukking.

De initiële productiekosten van het ontwerpen en bouwen van een applicatie met behulp van de DDD-methodologie zijn hoger, wat zeker van invloed is op het kleine percentage projecten dat op deze manier wordt geïmplementeerd.

Hoe gebruik ik DDD in mijn eigen project?

Om DDD praktisch te maken in ons project, moeten we eigenlijk helemaal opnieuw beginnen. Het is niet mogelijk om gedeeltelijk een Domain Driven Design-concept over te nemen waarbij de rest van het model op traditionele wijze wordt ontworpen. In dit geval zal de tevredenheid over het eindproduct zowel bij het IT-team als bij de eindgebruiker laag zijn.

Het is erg belangrijk om een ​​domeinexpert te vinden voordat u aan het werk gaat, die de specifieke kenmerken van het bedrijf en de behoeften kent en deze kan vertalen in duidelijke instructies voor ontwikkelaars. De keuze voor applicatieontwikkelingstechnologie bij het werken met DDD verdwijnt echt naar de achtergrond.
Artikelbeoordeling
0,0
0 beoordelingen
Beoordeel dit artikel
Ratmir Belov
Schrijf uw mening over dit onderwerp:
avatar
  Abonneren  
Houd rekening met
Ratmir Belov
Lees mijn andere artikelen:
Inhoud Beoordeel het Opmerkingen
Delen