8000 Promote the Anemic Domain Model as best practices? · Issue #7460 · symfony/symfony-docs · GitHub
[go: up one dir, main page]
Skip to content

Promote the Anemic Domain Model as best practices? #7460

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
Federkun opened this issue Feb 11, 2017 · 5 comments
Closed

Promote the Anemic Domain Model as best practices? #7460

Federkun opened this issue Feb 11, 2017 · 5 comments

Comments

@Federkun
Copy link

I was looking at the Symfony Demo application, and then I asked myself: it's really okay to promote anemic domain model as "best practice"?
I was reading the Doctrine Mapping Information section in particular:

Doctrine entities are plain PHP objects that you store in some "database".

But real entity has behaviors. From what I read there, I understand that "Doctrine entities are basically DTO".

I acknowledge that's the simpler way to explain how to build your "model", and for a demo app it's okay, but it isn't really a good practice, isn't it?
@VolCh
Copy link
Contributor
VolCh commented Feb 11, 2017

I think ever demo apps should demonstrate best practise, and at the Symfony Demo application some entities has few "not DTO" behavior like Comment::isLegitComment(). May be makes sense to add more behaviors to the entities and remove some anemic domain model marks like "stuppid" setters unnecessary in domain model like setAuthor (in a reasonable domain model author property should set only once on entity creation).

@javiereguiluz
Copy link
Member

Thanks for proposing this improvement. To move the discussion from the abstract to our specific application, which methods do you propose to add to our four entities? There's no need to show the code of those new methods, just their names. Thanks!

@felipsmartins
Copy link
felipsmartins commented Feb 24, 2017 •
edited
Loading

That's Data Mapper Pattern is for. A simple mapper interface. Adding more behavior than necessary deals with going to against the pattern. Doctrine isn't about Active Record.
Moreover, the previous link to Symfony best practices is about Mapping Information, whether format should be XML, YML, PHP or not. Regarding model behavioring is another thing, it's up to you.
:)

@javiereguiluz
Copy link
Member

Even if this issue is older, I'm closing it in favor of the newer #8893 issue where some people are proposing to make this change not only for the Best Practices doc but for the entire docs. Thanks!

@donquixote
Copy link

(I just found this issue randomly.)

I want to mention: The idea that "anemic domain model" === bad is not as clear as you may think.
Just because Martin Fowler said in 2003 that he doesn't like does not mean this is true forever.

A lot of recent articles suggest that an Anemic model may very well be superior to a rich domain model.
https://www.startpage.com/do/search?query=anemic+domain+model&cat=web&language=english
http://deliberate-software.com/anemic-domain-model/
https://blog.inf.ed.ac.uk/sapm/2014/02/04/the-anaemic-domain-model-is-no-anti-pattern-its-a-solid-design/
It is worth to do some research.

Of course it also depends on how you do it, not whether you call it rich or anemic.
I just say that the old "it's anemic, it's bad, Fowler said so" argument is no longer sufficient in 2018.

@donquixote donquixote mentioned this issue Apr 13, 2018
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@javiereguiluz @donquixote @VolCh @felipsmartins @Federkun
0