Progress Report: Chapter 05 (Part I)

Published: 2024-10-27

Current Stats:

• Words: 10,979 (most of this is phenomenal trash)
• Listings: 12
• Figures Used: 10
• Figures Made: 37
• SLoC (repo): 1,171

Chapter 5 is about domain behaviors. It takes the Leslie Lamport approach of seeing behaviors as "a sequence of states." Data in; Data out.

Originally, this was scoped very similarly to chapters 3 and 4 and lived in a happy world where things like databases and external service integrations didn't exist. I was going to focus exclusively on the modeling and data flows in isolation. However, it has been massively rescoped to include all those "unhappy" and "real world" things that make programming so hard. I think this makes it better. However, it's been very tough to find the right line to walk. The hard part about fitting "the complexities of the real world" into a book is that it takes pages just to setup that "world." The domain needs to be explained. Then the system needs to be explained. All of this burns pages just setting up what we're going to eventually talk about.

On a positive front, I made these calendars in draw.io. I am very pleased with them. My rectangle game is really coming around.

Plan for the next week

Make a final call on the acceptable complexity. Embedding the teaching into a "modern service-oriented hellscape" might be a bit too much to bite off at once. The main example is up to 4 service integrations and 4 distinct repositories – before we even start the main business logic.

// PREVIEW
class FeeChargingService {
	// stuff we integrate with to do work 
	RatingsClient ratingsClient; 
	ContractsClient contractsClient; 
	ApprovalsClient approvalsClient; 
	BillingSystem billingSystem; 
	// Stuff we own 
	CustomerRepo customerRepo; 
	InvoiceRepo invoiceRepo; 
	RulesRepo rulesRepo; 
	FeesRepo feesRepo; 

	public void createLateFees(LocalDate bookClosing) {
		// And so we begin! 
	}
}

This is something that's completely normal in the day-to-day life of a programmer, but feels so extreme in a book. Setting all of this up is not easy, but if I can finagle it, a lot of avenues open for exploring how we let data oriented programming reshape existing systems. We don't have to be bound by the choices that came before us. We can treat them as a substrate and build the world as we want it to be.

Or that's the idea anyways. We'll see if I can pull it into focus.