Domain Modelling

  2019-05-31


There are a lot of different ways to constuct programs. Given that I most often have used something like Perl, mine have tended to rely heavily on hashes, arrays, and scalars to slice and dice through all of the data. That works when you’re writing something that’s maybe a couple of hundred lines, but after a while, I have begun to see the value in more static typing. It’s sort of nice not to have everything blow up at runtime.

I have a really complex business process to solve, and I’ve been a little mesmerized by Scott Wlaschin’s Domain Driven Design. There’s something incredibly appealing about building the domain (salary, service, contributions, etc) and then breaking the huge calculation that I have mapped out into composed functions.

type Salary = Decimal
type Service = Decimal
type EeConts = Decimal
type ErConts = Decimal

type PayPeriod = {
  salary:Salary
  service:Service
  eeConts:EeConts
  erConts:ErConts }

type EmployeeRecord = PayPeriod list

What I am still trying to visualize is how to mix this with the incredible amount of SQL queries that this would need to be combined with. But, having these immutable, composable structures, seems like it will be easier to test and easier to run async and in parallel once I need to process thousands of them. He makes a very convincing case.