Is DDD only good for batch processing?

Question

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?

Answer 1

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

Answer 2

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

Answer 3

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.