I am posting because, first of all, I want to make sure my understanding on these 3 methodologies is correct. Secondly, I would like some clarification on how they could all fit in together. I see they are approaches used to tackle on different problems, and to me, it seems like they should all complement each other quite well because they address different levels of abstraction.

From what little exposure I've had to Functional Programming (Scala beginner), it seems to me like functional programming aims for idempotence and "real" functions are supposed to do one thing, and one thing only (no side effects).

Separation of concerns (having UI, application, domain, and infrastructure layers), along with having a ubiquitous language, and working closely with a domain expert on understanding the problem at hand before beginning implementation, is, from a high view, one of the biggest things DDD entails.

And then there's BDD, which seems to be an approach to TDD which takes some inspiration from certain aspects of DDD (especially the ubiquitous language and the importance understanding the domain has in design and implementation) in order to let tests drive development efforts.

Why do I say they complement each other? In a nutshell:

  1. TDD proponents say no design is necessary, just let the tests guide your code design. If you use BDD, though, you're making use of domain knowledge for your design, which relates to DDD. If you do some prior design work as in DDD, you're narrowing down your solution space from infinite to finite (and humanly approachable/understandable), which could help guide your tests and design
  2. Using BDD, your tests are supposed to test one thing only, and functional programming languages are great for this because functions are supposed to do one thing only, so this could help you design your functions and then have proof that they work because you've written a test for them.
  3. Because functions do one thing only, it should be helpful in enforcing a separation of concerns. So if you do DDD (higher level), a functional programming language should make it intuitive to implement the design (lower level) because of those features it enforces.

Am I completely wrong about any of these concepts, or am I making some sense?


2 Answers 2


First, some clarifications, since you expressed interest in checking your understanding:

Functional Programming (FP)

Functional programming is a paradigm in which the primary unit of program composition is the function; contrast this with object oriented programming, a paradigm in which objects comprise the primary unit.

Side Effects and Purity (or Referential Transparency)

You mention idempotence and "reality", when I think you mean referential transparency and "purity". Idempotence means that applying a function twice (or thrice, or...) is no different than applying it once.

"Pure" functions are those without side effects, such as writing to disk or sending data over the wire. It is not necessary for them to do only "one thing". You can replace a pure function call with its value without changing the behaviour of the program at all:

> // pure function
> const f = x => x*2;
> const a = f(2);
> a
> console.log(f(2));
> console.log(a);
> // impure function
> function g(x) {
... console.log(x*2);
... return x*2;
... }
> const b = g(2);
> b
> console.log(g(2));
> console.log(b);

Notice how, after replacing g(2) with its value, 4, console.log(b) writes one less line. This makes it (under some definitions) an "impure" function. This has nothing to do with doing "one thing only"; const g = () => { console.log("Hello world!"); } only writes to console, and yet replacing g() with its value, undefined, would not produce the same program (there would be no console output).

This property of being able to replace a function call with its value, without changing the behaviour of the program as a whole, is called referential transparency. I use it as one definition of "purity". There are many others.

Not all functional programming languages necessarily enforce purity; one could argue that JavaScript (and especially ES6) is a functional language, and yet as we've seen it is possible to write impure functions very easily in the language.

Languages like Haskell and Elm, however, make certain classes of side-effects very explicit via their type systems (e.g. the IO monad in Haskell, and the Signal applicative in Elm). Executing code with side effects is only possible according to certain constraints, enforced by the typechecker.

Domain Driven Design (DDD)

Domain Driven Design is a means of thinking about, discussing, designing, and actually implementing software with a cross-functional team operating in a rich and complex problem domain (e.g. finance). It's comprised of modelling the problem conceptually and linguistically according to a Ubiquitous Language, which pervades all aspects of the software - user-facing language in the UI, conversations with designers, domain experts, class, file, and variable names in the code.

This conceptual model and the Ubiquitous Language used to describe and talk about it only apply within a Bounded Context, which you can think of as a namespace; a Ticket may refer to one thing in the context of Customer Support, and another thing entirely in the context of Cinema.

Separation of Concerns

On the level of the actual software implementation, DDD encourages us to model the problem domain, its structures, relationships, and constraints, as closely as possible within the code. This representation of the DDD conceptual model lives within the domain layer of code, which is exercised from the outside (via a GUI, a CLI, a webpage, etc.) via the application layer, which "plugs in" the domain into an environment where the operations of the domain are exposed. This layer encapsulates all technical details (broadly speaking) of the application; contrast this with the domain layer, which is exclusively concerned with the "business logic" of the problem domain. This is the separation of concerns you allude to, and while it is quite important, I would say that it is not the primary focus of DDD.

Relationships Between the Three

DDD and FP - Side Effects and Separation of Concerns

Domain Driven Design, extending beyond the mere software solution and its implementation, and into the minds of all people involved in the software's use - its end-users, maintainers, designers, and software developers - does not prescribe (to my knowledge) the use of any particular programming paradigm.

However, some functional programming languages are well suited for achieving the separation of concerns you describe; for instance, "business logic", operating on data types representing the Entities and/or Value Objects within a given domain, could be restricted to pure functions, or those without side effect. In order to actually execute this business logic, it could be plugged into, say, the IO monad from Haskell, where it would then be able to communicate over the network, or read and write files from disk. It would not be possible (in theory) to have technical concerns leak into the domain layer, since all application-level detail must take place in IO. This is possible because languages such as Haskell make side-effects explicit at the type level.

FP and BDD - "Doing Only One Thing", and Referential Transparency

If we proceed under the above definition, in which pure functions are those which can be replaced by their value without changing the way the program runs (referential transparency), the principle of "doing only one thing" becomes irrelevant to the question of whether or not FP is well-suited to BDD. I think the two topics are somewhat distant.


They're pretty related. Cucumber is great.


Functional Programming and Domain-Driven Design are in some sense orthogonal to one another; DDD makes no hard prescriptions on what language or technology to use. However, the principle of separation of concerns, which DDD does employ in its separation of domain and application layers, can be easily achieved in some functional programming languages with explicit side-effects. Pure functions need not do only one thing; they only need by referentially transparent. FP's connection with BDD is tenuous; BDD's connection with DDD is quite close.

Hope that helped. Just sharing my own understanding, which of course is always in need of revision.

  • "Idempotence means that applying a function twice (or thrice, or...) is no different than applying it once.": In the case of a pure function, this would mean that the function is the identity on a subset I of the domain, and maps all inputs outside of I to some value inside I.
    – Giorgio
    Commented Feb 25, 2017 at 6:46
  • That is definitely a more precise way of putting it. Another equivalent formalization I have read is that the image of an idempotent function is its fixed set: proofwiki.org/wiki/Fixed_Point_of_Idempotent_Mapping
    – evocatus
    Commented Feb 26, 2017 at 5:14
  1. TDD proponents say no design is necessary ...

No, TDD proponents say allowing for tests in your design can only improve your design. They don't say you have an awesome design just because it's a testable design.

Let me explain it this way:

Testable == well designed? False
Testable -> well designed? False
Testable <- well designed? True

You have to DESIGN period.

Why? Because a good design is MORE than just testable.

  1. Using BDD, your tests are supposed to test one thing only ...

This is true of unit tests. BDD is about more than unit tests, and for that matter, so is TDD.

  1. Because functions do one thing only ...

f(g(x)) could be function h that does two things, an f thing and a g thing. You're confusing returning one thing with doing one thing.

The single responsibility principle is where the idea of "one thing" comes from. You can find it followed in functional and object oriented programming alike. None of these make following this principle easy. I can bloat functions as well as objects with needless crap that should be handled elsewhere if I'm not careful.

There is no crutch that will make this something you don't have to think about. You have to remember it and follow it or you'll make a mess in any paradigm.

  • Well I didn't mean it as a crutch that would make you not think about it. I rather meant it as a tool that would help not go off the rails so easily. When I said no design is necessary, I meant more like no design up front, which might still be wrong. Then again, that's why I made this thread, because I want to gain a more clear understanding (and know where I may have misunderstood things, or just plain unluckily read from the wrong source). As for your f(g(x)) example, I could be wrong, but I still interpret it as one thing: g: A -> B does one thing and f: B -> C does one thing.
    – bitterman
    Commented Feb 24, 2017 at 14:57
  • I'll try to explain it one more time: h: A -> C does two things. A g thing then a f thing. It's not that bad if you use f and g to define h. But if you just write h and never write f or g then you're screwed when you discover you need a B. Trust me. There is no paradigm that a determined programmer can't make a mess in. It's dangerous to think there is. Commented Feb 25, 2017 at 0:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.