[フレーム]
BT

InfoQ Software Architects' Newsletter

A monthly overview of things you need to know as an architect or aspiring architect.

View an example

We protect your privacy.

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Unlock the full InfoQ experience

Unlock the full InfoQ experience by logging in! Stay updated with your favorite authors and topics, engage with content, and download exclusive resources.

Log In
or

Don't have an InfoQ account?

Register
  • Stay updated on topics and peers that matter to youReceive instant alerts on the latest insights and trends.
  • Quickly access free resources for continuous learningMinibooks, videos with transcripts, and training materials.
  • Save articles and read at anytimeBookmark articles to read whenever youre ready.

Topics

Choose your language

InfoQ Homepage News Functional Patterns in Domain-Driven Design

Functional Patterns in Domain-Driven Design

This item in japanese

Lire ce contenu en français

May 31, 2014 1 min read

Write for InfoQ

Feed your curiosity. Help 550k+ global
senior developers
each month stay ahead.
Get in touch

Domain-Driven Design (DDD) does a great job in encouraging developers to create a domain model and an ubiquitous language, but trying to implement DDD concepts using object orientation principles with state and behaviour often gives you a muddled mutable model, Debasish Ghosh states in a blog post about functional patterns in domain modelling.

Debasish, a senior member of ACM and author of DSLs in Action, argues that a model may be rich in the sense that all concepts related to a particular domain abstraction are located in one class but that this also makes the class more fragile with a local instead of a global focus, thus when composing all abstractions in a domain it may become too polluted with code just needed to resolve the impedance mismatch between class boundaries.

In his arguing he refers to Dean Wampler who recently argued that functional programming principles can help improve in domain driven design. Dean claims that "Models should be anaemic", encouraging a practice with domain objects having only state and moving behaviours into standalone functions.

Another statement Debaish argues against is that bundling state and behaviour in a class increases encapsulation, instead he believes that building domain behaviours as standalone functions leads to a better modularization and realization of the domain model according to the principles of DDD. All domain behaviours are then modelled as functions in a module representing the aggregate.

As an example he continues from earlier blog posts where he implemented the Specification and Aggregate patterns in DDD using functional programming principles, now using functional patterns and functions as building blocks to build behaviours that model the ubiquitous language of the domain. Debaish claims that one principle in DDD is to lift the domain model vocabulary into your implementation so that the functionality becomes obvious during the whole system lifecycle.

Dean Wampler also did a presentation on a similar topic at the React conference in April talking about reactive design and language paradigms.

Rate this Article

Adoption
Style

Related Content

The InfoQ Newsletter

A round-up of last week’s content on InfoQ sent out every Tuesday. Join a community of over 250,000 senior developers. View an example

We protect your privacy.

BT

AltStyle によって変換されたページ (->オリジナル) /