Declarative Domain Model possible (DDD)?

Question

I'm looking for insight/ papers/ articles, etc. whether a fully declarative Domain Model (as per DDD) is possible.

For example:

• Validation can be declarative (lot's of ORMs do this)
• business flow logic can be declarative: having a DSL for defining a workflow / Finite State Machine / process manager / DDD Saga (whatever you want to call it) on Crud-operations, through ddd-repositories most likely
• decision logic can be declarative. I.e: most of the time this boils down to simple conditionals
• derived / calculated fields could be done declaratively but is as bit tricky, especially when this cascades. I.e: you'd have to keep a dependency graph on the calculated fields, etc. Still it can be done.

Any links to people having actually tried that, or some convincing couter-arguments why this can't be done?

p.s.: Please don't answer with "Yes it can be done, since a FSM is Turing-complete with enough memory bla bla"

Answer 1

"Everything is a nail if you hold a hammer"

Instead of asking if it is possible - ask: What are the reasons I want to do this particular thing declaratively?

Data validation is a nice thing to do declaratively. You have a DTO, you add some attibutes, everything is clear and readable.

Business flow done declaratively... Reminds me of a great failure of Windows Workflow Foundation. Is anyone actually using it? What is the benefit of making a behaviour-centric components in a declarative way? Imperative way seems to be well-fitted to this. Decision logic... maybe. But again - why?

"derived / calculated fields could be done declaratively but is as bit tricky" Why do you want to do tricky things when there is a way of achieving the same result with straightforward things?

So why? Do you need to change the behaviour of the app in runtime by editing some config file? OK, go for it.

Do you have a generic domain that will be used by many clients and you need some reconfiguration to fit them? Ok, but you need to clearly distinguish the unchangeable core of your domain and the varying stuff. Don't try to make all the things configurable - you'll end up with Inner Platform syndrome.

Do you believe you can make a declarative language your client could use to change his domain without a need for a programmer? No. You will fail. I know a language which was supposed to be like this. An easy, declarative language that ordinary accountants would use to explore their data. It's called SQL :D

Answer 2

I fully concur with Bartłomiej Szypelow's remark. Regardless, I will try to answer your question.

A declarative language always depends on an imperative language for it to work. Take something as simple as arithmetic for example. When we ask for the outcome of 1+1 we first need to know how the 1 should be understood and how in that context the + operator can be calculated before the statement as a whole can be interpreted. This is one of the ways we are able to overcome complexity; you don't need to know how a plus operation is done to be able to use one.

From http://en.wikipedia.org/wiki/Imperative_programming:

Procedural programming could be considered a step towards declarative programming. A programmer can often tell, simply by looking at the names, arguments and return types of procedures (and related comments), what a particular procedure is supposed to do, without necessarily looking at the details of how it achieves its result. At the same time, a complete program is still imperative since it 'fixes' the statements to be executed and their order of execution to a large extent.

In any domain the same applies. If you ask the flight attendant to reschedule your flight she knows what a flight and a passenger is and how to reschedule one. Creating a fully declarative flight scheduling domain model without describing how scheduling works is therefore impossible. Since all domain models contain operations/behavior it is therefore equally impossible to create a domain model in a declarative language unless your problem domain is not unique, for example when you have three flight companies that operate in similar fashion.

Back to why... you said:

Actually, the hypothetical reason why is actually to allow non-coders to create a (trivial) backend by configuration

Declarative programming is not always simpler than imperative programming. Most of the time people tend to think in outcomes, but sometimes the outcomes are so varied that it is (much) simpler to think in steps. This is the reason why these different styles exist and continue to exist in the first place. The main difference between a coder and a non-coder is not that a non-coder tends to think in terms of outcomes instead of processes, but that the non-coder simply does not want to be bothered with the workings of a computer. The non-coder wants to focus on the problem. Depending on the domain a non-coder may be helped best with an imperative DSL, instead of an declarative DSL.