Opening the thread for Chapter 2 – Communication and the Use of Language.

This chapter moves us closer to the interface between language, code, and clarity. Evans argues that the model should not be something floating outside the implementation, rather the best code should reveal the model directly. The diagrams and documents we write should support that, not compete with it.

A few lines that stood out:

“The vital detail about the design is captured in the code. A well-written implementation should transparently reveal the model underlying it. Supplemental diagrams and documents can guide people’s attention to the central points. Natural language discussion can fill in the nuances of meaning.”

“Rather than a diagram annotated with text, I write a text document illustrated with selective and simplified diagrams.”

“A document shouldn’t try to do what the code already does well. The code already supplies the detail. It already is the ultimately exact specification of program behavior.”

I really liked the clarity with which Evans modelled the cargo shipping system in this chapter — especially how each object served the model, not just the database or UI. That made me want to try something similar myself.

Example: A Library Borrowing System

There are Books, Users, Loans, and Return Policies. We could model it roughly like this:

  • Book: title, author, ISBN, category
  • User: name, user ID, membership type
  • Loan: ties a User to a Book, tracks issue and return dates
  • LoanPolicy: applies different rules based on membership type (e.g., 14 vs. 30 days, renewals, fines)

The idea is to keep logic like due dates and renewal rules in the domain layer (LoanPolicy) rather than scattered across UI forms or database constraints. And if we ever added exceptions (e.g. faculty borrowing journals), that should show up in the model too — clearly and early.

Library Borrowing System Model

This is off the top of my head, feel free to suggest changes / add usecases / point to mistakes.

If there’s anything interesting you’ve thought about modelling or a problem you’d like to pose to others to think through or just general thoughts on the chapter, feel free to drop it in the thread. Doesn’t have to be from work or even fully formed.

Rohit

"best code should reveal the model directly" — this is extremely true, when the code is well written, you just know it. Otherwise its about going back and forth and messing around to understand whats going on.

Challenge for the Reader

  • Try modelling a system you work with daily using only domain objects — no database tables, no UI fields. What changes?
  • Take the Library Borrowing System above and add a use case: a student requests an extension on an overdue book. Where does that logic live?