Domain-Driven Transformation

Chapter 3. Domain-Driven Design

Tip

This chapter presents knowledge that is foundational for Domain-Driven Transformation. If you are already familiar with Domain-Driven Design, you can skip this chapter and come back to it later for reference.

Domain-Driven Design (DDD) is a philosophy of software development that places the business domain at the center—not only during requirements analysis, but especially during modeling (see “Modeling in Code”) and programming. This chapter is a distillation of our view of the DDD knowledge that was gathered over the last decades—from both literature and contributions of the community—with a special focus on legacy modernization. So as to not only present abstract theory, we describe the concepts with another concrete case study.

Modeling in Code

Note that “modeling” as expressed here is not considered a separate step from programming, such as when drawing UML diagrams or by using some other graphical notation.

Of course, programming is where code is written. In fact, there might be no diagrams (pictures) drawn at all during modeling. It could be that modeling happens with only the use of programmed tests that are first red and then green as the domain model is progressively implemented. The resulting programmed model is the model itself and the modeling took place as a pure programming exercise.

There is nothing wrong with doing part of the modeling on a whiteboard or using drawing tools, and even Collaborative Modeling tools as presented ...