Implementing Domain-Driven Design by Vaughn Vernon goes through an implementation of an application in Java using Evans’ DDD principles. I may disagree with some of his code, and some of the “dialog” is hokey, but it is a useful read.

I’ve been doing this coding thing for a while (30+ years) and I find it’s really difficult to convey how “real world” problems get solved, because much of the solutions are specific to the team and company culture involved, and less about the technical aspects. Yes, for those who give talks at QCon or O’Reilly conferences, they have unique problems, but 80% (if not much more) have the same issues: lack of modularity (hence monoliths), poorly written tests (let alone coverage), and a shallow understanding of the domain (which is why I talk a lot about domain-driven design).

I really liked the Architecture of Software Applications books, because it’s one of the few places that walks through how something that you might actually be using was created, and the constraints involved.

I also thought Practical API Design was a really good case study of writing a framework. Growing Object-Oriented Software (aka GOOS) is also a solid read (and generally matches how I think and do software development).

Yes, many books use toy or simplistic examples, partly because it’s really hard to teach someone a non-trivial domain while at the same time teaching them something non-trivial about a certain type of problem/solution, I also find most authors aren’t able to, or don’t want to, put in the work necessary to create more realistic examples. As an author and instructor, it definitely is more work, but is also a better way to teach. Alas, the bar is pretty low for how programming is taught.

Domain Driven Design by Eric Evans is a classic modeling book, but a hard read. I’ve heard that Domain-Driven Design Quickly by Abel Avram & Floyd Marinescu is a better, shorter version but haven’t read it.

I got a lot out of Joe Celko’s Data & Databases on database design and, his puzzle books SQL for Smarties and SQL Puzzles and Answers puzzles were so fun and weird they helped me really internalize relational dbs.

I just started Scott Wlaschin’s book Domain Modeling Made Functional and Debasish Ghosh’s book Functional and Reactive Domain Modeling. I’m only about a chapter into each, so I can’t give a significant opinion yet, but they’re both interesting takes on modeling.

Jon Bentley’s Programming Pearls books and Writing Efficient Software have lots of the bitpacking kind of stuff you’re getting at in your mention of Stockfish.

Sandi Metz & Katrina Owen’s book 99 Bottles of OOP breaks down a toy problem in a bunch of different directions and points out where approaches succeed and fail at responding to change or preventing bugs.

The architecture of open source applications should be real-world enough

So, I’ve been thinking that we really should have a wiki or book somewhere of standard business problems. Things like “this is basic inventory system”, “this is basic user manage”, and so forth, along with common design parameters and operating regimes.

A super common example for “clean code” is that instead of doing p * t to add sales tax, you write price * sales_tax. I pulled up an ecommerce suite and looked how they did it. They track an array of the tax markups, one for each applicable tax, and bundle that along with the cart.

btw, “clean code” (I hate that name, I prefer “intention revealing code”) is much more than nicely named variables, it’s well partitioned code at multiple levels. Short methods with meaningful names, divided into classes that are cohesive, divided into modules, etc., with cohesion at each level, and each one being at the same level of abstraction.

I took a look at the tax.php code and, while I’m no PHP developer, that’s not at all how I’d do it, because that code isn’t OO, it’s just code that happens to have method names. We can argue about OO vs. FP, but if I were to write this as OO code, I wouldn’t have code like this (in fact I’d hardly have if statements at all):

if ($calculate != 'P' && $calculate != 'F') {
	$amount += $tax_rate['amount'];
} elseif ($tax_rate['type'] == $calculate) {
	$amount += $tax_rate['amount'];
}

That’s a sign that the author doesn’t understand OOP, or didn’t want to do it.

I think the best way to find out how it’s really done is, as you’ve already found, to look at how it’s really done. Plenty of “real-world” implementations of solutions are open source, which not only gives you the opportunity to see their code but also to see their commit history. Maybe that chess solution started to “make it work” with a piece being an object, but by the time they got to “make it fast” went to the bitmap approach.

Books have noddy examples not because the authors don’t know how to do tax or chess games, but because their goal is to teach something else. I once wrote a shockingly bad stack overflow browser to teach TDD, not because I wanted to demonstrate a shockingly bad stack overflow browser but because I wanted to teach TDD.

For a very good perspective of modeling complex problems outside the domain of informatics and computing infrastructure, it is worth reading (informational) parts of the manual for the Beta language, the successor to Simula. It can be found on the web.

It provides insight into the “programming is modeling” perspectives of the inventors of object-orientation. Interestingly, this is the same (unpopular) perspective of Domain Driven Design as promoted by its original author.