Just read my first book on DDD ("Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#" by Scott Wlaschin in case it makes any difference), and came away with the distinct impression that DDD is great for batch processing, but not necessarily so good for other things.

His example was an order processing system, where the input is a paper form from the customer. The unvalidated data goes into the first stage in the workflow, where it's converted to a validated order (or bounced back if invalid), which is the input to the second stage and so on. The end result is a bunch of events indicating what happened and/or should happen next. This is very much an uninterrupted pipeline.

By contrast, the majority of my work involves pulling data from a database, displaying it on a web page of desktop window, waiting for the user to make some modifications, and then saving the modified data back to the database. I can't really see how DDD would help there. It's only really a one-stage workflow.

Did I miss something, or is DDD only really useful for batch processing?

  • 5
    DDD is useful when you have a very rich domain, with many business rules you want to encapsulate in an isolated layer. If you only do CRUD operations, then no, DDD is not useful (or at least not as useful as it can be, and probably a superfluous overhead). May 22, 2018 at 15:45
  • That makes a lot of sense. So I might use DDD just in the business logic layer when the data gets sent back to be saved? May 22, 2018 at 15:48
  • see Discuss this ${blog}
    – gnat
    May 22, 2018 at 15:55
  • DDD can be applied and will bring a lot of advantages when applied correctly. And that's even for small project. I suggest watching this talk youtube.com/watch?v=h6WvetICeo4 May 22, 2018 at 15:56
  • You should not understand that DDD is equal to some architecture presented in a book, not even in The DDD Book (4 Layer Architecture). There are many good take-aways from DDD, the most important being the ubiquitous language and bounded contexts. May 22, 2018 at 15:59

3 Answers 3


DDD is an approach to building domain models, focusing on clear communication and shared concepts. In my opinion, that means that it's suitable for any domain, and complex ones in particular. When the going gets complex, it's important to have a design that is based on a deep understanding of the domain. In the "Domain Modeling Made Functional" book a relatively simple domain was used in order to focus on what is new to most readers: the use of algebraic types for domain modeling, and the functional approach to implementing a workflow.

As to "batch processing", the book uses functions (of course) to model workflows that are initiated by events. In an object-oriented design, the workflow might be represented as a method on a service. In neither case is this equivalent to the traditional definition of "batch processing".

It's true that there are some parallels. In a functional approach, just as in a batch process, the data is generally processed in a pipeline, being transformed at each step along the way. But a function call can be completed synchronously in milliseconds, so it's not quite the same :)

  • Thanks for the answer. When I said batch processing, I was thinking along the lines of a set of operations (ie a pipeline) that happen on the input data, transforming into output data and/or events, as opposed to my scenario, where very little (of interest) happens to the data, it just gets passed from a UI to a database, with perhaps some validation in between. However, between all the answers I got, I can see how it might be useful in my scenario, albeit for only part of the process. May 23, 2018 at 13:29
  • 1
    Thanks for the clarification! I would call an application that does not transform the data in any way between UI and database a "CRUD" app, and for those types of apps, DDD probably is overkill, yes! Even so, I think it's always a good idea to spend some time understanding and documenting even a simple domain, as they often can be more complex than they appear!
    – Grundoon
    May 23, 2018 at 13:46
  • Also, even in a CRUD app, having the validation rules captured in types can help with documenting the code and avoiding bugs.
    – Grundoon
    May 23, 2018 at 13:48
  • Thanks again, great comments. Maybe you could include them in your answer, to make it clearer for anyone else who might read the thread. May 23, 2018 at 13:50
  • @AvrohomYisroel DDD is overkill for a CRUD app but there are hardly any truly 100% CRUD apps out there. Even if your app logic appears trivial at first sight ("perhaps some validation in between" as you said) it tends to become not so trivial in a blink of an eye. It will result in much more headache if you try to "save" some keystrokes and thrust everything (e.g. data access, validation, trivial domain logic etc.) into one class or data type rather than make a clear separation between those concerns. This is what Scott's book and F# blog is about.
    – KolA
    Mar 26, 2019 at 21:40

DDD only really useful for batch processing?

No, domain driven design is useful for modeling complex domains.

Your primary reference is "the blue book" by Eric Evans. If you happen to have a copy handy, Martin Fowler's Patterns of Enterprise Application Architecture has a brief discussion of the domain model pattern in comparison to some other designs.

Two things that may be unfamiliar, and therefore confusing

1) The more important part of a domain model is the bit that manages change; the model includes the logic that decides, for example, what gets stored in the database; are the user's modifications valid, are the user's modifications consistent with the information that is currently stored in the database, and so on.

2) In many cases, your application can be cleanly separated into two parts - the core domain logic that manages the integrity of the data, and the plumbing that moves messages around. From the point of view of the core, most applications do have an uninterrupted pipeline when making changes. I'm in this state, I received this message from a user, so I should now be in that state.

That said, rich domain modeling isn't always the best fit for purpose; if your are just a database, storing information for later retrieval, then building a domain model for that may not be cost effective. It becomes more important as you move on the spectrum from "database" to "service".


His example was ... very much an uninterrupted pipeline.

Not sure what you mean by "uninterrupted". If you mean "happy path scenario" then this is not true. Primary focus of the book is explicit modelling for both failure and happy path. There's a separate chapter of how to do error handling in 100% explicit and type safe manner, unlike just throwing an exception (think Total functions) and keep function composition nice and simple at the same time (think dreaded Monads).

Probably what you mean by "uninterrupted pipeline" is what Scott calls a "workflow"? Yes workflow is basically any kind of largely uninterrupted (in a sense that it doesn't require extra input) operation performed in response to some event that triggers it, whether it is a command from UI or anything else e.g. a scheduled task / offloaded processing such as sending off emails (in this case output of one workflow becomes input of another workflow).

Application can have many workflows, it definitely doesn't have to be just one workflow for batch processing, whatever specifically is meant by that. Book says explicitly what it means under "domain": "anything that domain expert is expert in!" i.e. Functional approach to DDD is a very general design approach.

Any domain can be represented as a set of strongly typed data types and actions(functions) that transform this data and can be composed into pipelines where one pipeline is basically a workflow.

Book describes the benefits of doing DDD in functional manner which are not available in object oriented languages, however this is out of scope of the question.

Your Answer

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

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