Within DDD, the idea is to allocate all logic (as much as feasible) to the entity POJOs. This often includes logic of the following categories: accessing state (setters, getters, navigation and change of object graph), validating the state, calculation of derived attributes (calculating order sum of an order) and event processing (action-logic triggered by changes to the state of an entity, such as producing a shipment note when the order state is changed to “ready-for-shipment”). With large systems, there are usually context-specific (e.g. use-case-specific) needs that influence what methods we add to the domain classes. This creates problems over time when there are a lot of context-specific change requests that require new versions of a shared domain model implementation. With dynamic languages it is straightforward to separate these concerns without sacrificing the sought-after programming model of "intelligent pojos". There is also a new architecture (DCI) that take the reasoning further, towards a formal architecture for separation of concerns that is driven by the same core problem: how to get the fruit of DDD without the downside of a fragile domain model? This presentation illustrates pragmatic CDI with the power of a dynamic language (Groovy).
Domändriven design förknippas med programmeringsspråk, ramverk och kanske modellering för att kunna beskriva och realisera system – både data och logik – utgående från den information som hanteras. I praktiken handlar det för oss utvecklare om att få fram programkod som i form av klasser, metoder och kanske mappningar mot databaser representerar domänobjekten. Vi har blivit ganska bra på att bygga EN applikation / ett system i ETT team enligt denna modell. Vi har olika sätt att fördela logik mellan tjänster och domänobjekt. Så länge det är ett utvecklings/förvaltningsobjekt (gemensamt ansvar) för alla lager, behöver vi inte fundera så mycket på hur förändringar påverkar olika lager. Vi kan prioritera en domänmodell med mycket logik för att få en objektorienterad programmeringsmodell. Det är helt ok att domänklasserna förändras i varje release av produkten. I en rik domänmodell kan koden bli svår att förstå. Det är lätta att fragmenteringen gör att man tappar greppet om helheten/användningsfallet. Det en baksida av att prioritera återanvändning. Det gör också att det tar ganska lång tid för nya medlemmar i teamet att bli produktiva. Eftersom vårt system är ett “ stuprör ” samverkar det med andra system genom integration. Komplexiteten ökar gradvis när nya användningsfall tillkommer. Förr eller senare önskar vi att vi hade ett mer procedurellt angreppssätt
DDD blir betydligt mer komplext när systemet blir större och behöver modulariseras. Domänklasserna får fler intressenter och det blir plötsligt vikltigt att domänmodellen releasas separat och att den hålls så stabil som möjligt. Vi behöver hitta sätt att partitionera domänmodellen. Vi får svårare att knyta logik till domänklasserna eftersom all kunskap om användningsfallen inte finns fullt ut hos alla i teamet som är beroende av domänmodellen. Det blir svårt med relase-hanteringen när två team med olika leveransplaner är inne och hackar i domänklasserna.
Håller man fast vid att ha logik i domänklasserna (vad som tillkommer pga ett use-case och vad som “ tillhör domänobjektet och har återanvändningspotential ” är ju en glidande skala. Det kostar möten och det kostar samordning, vilket fördyrar och komplicerar