Domain Modeling Made Functional

Wrapping Up

We’ll stop gathering requirements now, as we’ll have plenty to work with when we move to the modeling phase in the second part of this book. But first let’s review what we’ve learned in this chapter.

We saw that it’s important not to dive into implementation details while doing design: DDD is neither database-driven nor class-driven. Instead, we focused on capturing the domain without assumptions and without assuming any particular way of coding.

And we saw that listening to the domain expert carefully reveals a lot of complexity, even in a relatively simple system like this. For example, we originally thought that there would be a single “Order,” but more investigation uncovered many variants of an order throughout its life cycle, ...