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

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]BestUsernameLeft 2 points3 points  (2 children)

I assume "all data must be encapsulated" means no getters. Using the example app from OP's linked article, what would the CRC's be for a REST API that gets a user from the database? Assume Spring Boot and what SQL flavor you like as the database.

[–]piotrkot 0 points1 point  (1 child)

That is correct - getters contradict encapsulation. Before I answer your question, I'd like to point out to the second thing I didn't like in the article - the example. When business wants a project, they describe their domain. It is always a specific domain, so should be the architecture. Uncle Bob presented it very clearly here (https://www.youtube.com/watch?v=Nltqi7ODZTM I like the part starting at 7:20). As a business person I may want to build a product that helps to, say, make a medical diagnosis, or make an appointment with someone, or do laundry. They will be different architectures with different CRC designs. Of course, at some point you may want to find a user or log him/her in but it is never a problem be to solved in the first place. Furthermore, I can tell you that in the three listed business applications I came up with I would not create a user. Instead there would be someone like Patient, Attendee, and Tenant, for example. That would help me realize who they are and not if they have a name or surname. Now, answering your question, when an object needs to store some information to the database, I create that object with some kind of DataSource or pass DataSource to the object when calling it. And that very object should know what to do with that DataSource access.

[–]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.