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).