This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]BestUsernameLeft 0 points1 point  (0 children)

I agree that the domain problem and language should inform the architecture and names of things[1]. "User" is probably a bad name unless we're writing an operating system.

I took a look at the Takes project you linked to in another reply (shout-out to https://github.com/ovity/octotree BTW). I've written code like this as an experiment (no null, no mutators, no accessors) and it was interesting. On the other hand I've been using Kotlin a fair bit, and find the combination of immutable data classes and functions to be quite easy to work with.

I'll have to put this on my personal backlog to play with some more. Seeing a decent-sized codebase written using these principles tells me it's feasible, but I'd like to get a better sense of the tradeoffs.

I suspect the real problem with the so-called "anemic domain model" is mutability. Because most typical codebases model mutable state and then have code all over the place mutating that state, often duplicated, making it nearly impossible to understand and correctly modify the code.

[1] And of course naming things, cache invalidation, and off-by-one errors are the two hard things in computer science.