The Clean Architecture - entities design

[Łukasz Duda]

Hi Uncle Bob,
It's been five years since I first tried to implement The Clean Architecture. As I used it multiple times, a few questions have came up to me.
I wonder if you'd be so kind and take some time to explain several decisions.

1. Do you always put the use case object in the center? Have you noticed the influence on entities? I've found some suggestions about rich domain-objects. Do you prefer to keep entities simple?
2. "Entities encapsulate Enterprise wide business rules." Does it mean, that all applications in the enterprise should share the same entities model? Did you consider what's the best way to implement separation of entity-families?

Best regards
Łukasz Duda

[Norbert Nemes]

Hi Lukasz
Entities encapsulate the app-independent business rules. This does not necessarily mean that the whole enterprise SHOULD use the same entities. Just that they CAN. If they want to. Think about something like a cart, or an Employee. Other applications in your business could use those, and if they did, they could do so without any modification to the behavior of those entities.
As for use cases, yes they should be in the center. I’m not sure what this effect on the entities is that you mention. One thing that is kind of missing from UB’s books and it was an epiphany for me when I heard him talk about them in his Clean Architecture semirar was the concept of high-level use cases. Use cases that execute other use cases and coordinate between them.
Hope this helps!

[Łukasz Duda]

I guess my main issue is that focus on "command-like" use case objects often leads me to anemic entities. I wonder if it's intentional (ideally from the author's perspective), that using this architecture, we should try to keep entities simple and enterprise-wide.

[Łukasz Duda]

I'll try to put this in a different way..

Does anyone have an example of rich entities in combination with use cases expressed as objects?

Can you name pros and cons of use case expressed as:
1. a class simillar to command pattern

2. method of an entity?

Are there any other ways to express use case?

Do you know pros and cons of rich and anemic entities?

Thanks in advance

Regards

Łukasz Duda

[sorin cristea]

here its a good example of a rich model vs anemic : https://www.link-intersystems.com/blog/2011/10/01/anemic-vs-rich-domain-models/

actually all this 'rules' about clean architecture are the OOP principales: Demeter law(https://dzone.com/articles/the-genius-of-the-law-of-demeter) , good encapsulation, low coupling between classes, SOLID principales .

If your application will have a complex business, you'll have business into use-cases and on entities, otherwise your app will look as an over engineer if you apply 'clean architecture'

hope this helps

Sorin 

--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.
To post to this group, send email to clean-code...@googlegroups.com.
Visit this group at https://groups.google.com/group/clean-code-discussion.

--

Sorin Cristea

[Luiz Augusto Moreira Costa]

Hi Lukasz, 

I think the best way to think about use cases or commands, is to think it act as coordinator. it doesn't do anything, just coordinate the entities to achieve a goal. The main responsability of a UC is organize the application logic. For a simple example, imagine a blog system. We can have 4 important concepts: author, reader, article and comment and 2 use cases: publish an article and comment an article. How we can implement these use cases to coordinate the application logic? So I'm big fan of domain driven design, then my implementation is very influenced by this. Let's take a look at the "publish article" use case.

class PublishArticle

def execute(author_id, title, text)

author = author_repository.get_by_id(article_id)

article = author.write(title, text) ## article_factory.create(title, text)

author.publish(article)

all_articles.save(article)

end

end

It is a very simple example, but the use case doesn't know how to publish the article. If the logic is simple or complex, it is not the use case responsability . Another important point is the use of the business language to add responsability to entities. The article.write method, makes more semantic the flow. In a anemic model way, I think, it can be similar to this:

class PublishArticle

def execute(author_id, title, text)

article = Article.new

article.title = title

article.text = text

article.author_id = author_id

article.published = true

article.published_at = DateTime.now

save_article(article)

end

end

In this implementation, we don't have the advantage to use the flow to increase the abstraction level. I put a very simplified logic to publication here, just for ilustrate the problem, but it can be more complex than this. Another important point, is in this case, the use case to know all the logic to publication, if it changes, the use case change too. 

Here another implementation example: 

class CommentArticle

def execute(reader_id, article_id, comment_text)

reader = reader_repository.get_by_id(reader_id)

article = article_repository.get_by_id(article_id)

comment = reader.comment(article,comment_text)

article_repository.save(article)

end

end

Again, I would like to highlight the flow. This use case doesn't know how a comment is created, how a comment is saved, etc.

This is a very simple domain, and I thought 10 minutes about this to write this answer, so, there more interesting domains to apply this style.

It was helpful?

--

[Łukasz Duda]

Thank you for the articles and nice example. It was very helpful.

I see that most publications say that rich entities are better than anemic.

There's one more thing, that makes me curious. If you look at https://github.com/cleancoders/CleanCodeCaseStudy/tree/master/src/cleancoderscom/entities
or
https://github.com/cleancoders/CleanCodeCaseStudy/blob/master/src/cleancoderscom/usecases/codecastSummaries/CodecastSummariesUseCase.java
you see that entities are simple and most of rules are in a use case.
I got the impression, that Uncle Bob and Micah did it on purpose. For exapmple isLicensedFor. I suppose they didn't want to move that rule to entities. I wonder why?
* Was it too simple example, to demonstrate rules in entities?
* Were they thinking about different applications in enterprise, where User has nothing to do with license?
* What are advantages of simple entities?