2

I'm reading chapter 20, "Business Rules", of clean architecture book, in this chapter Uncle Bob defines entities as:

An Entity is an object within our computer system that embodies a small set of critical business rules operating on Critical Business Data. The Entity object either contains the Critical Business Data or has very easy access to that data. The interface of the Entity consists of the functions that implement the Critical Business Rules that operate on that data.

I understand that entities are domain objects that could be used in any context of the application because it's "self-sufficient" with its own rules and validations, but what about objects that do not have "strong" and "critical" business rules that could be used in any context? just simple data holders, anemic classes, are they considered domain objects? can use-cases be coupled to them just like it is to entities?

A simple example of a specific scenario:

I have a Use Case to create blog posts with images, in which the user can send URLs of images uploaded on an amazon s3 server, and in the back-end there's a check to see if the provided URLs are valid, if so the post is created with these images URLs.

On the Use Case, for the URL check I use the Amazon S3 API encapsulated as a generic adapter, something like ImageStorageAdapterInterface with the method getImageByUrl(), which returns a simple object with metadata such as url, created_at, expire_at, size, and so...

I could have considered this object as an entity and name it something like UploadedImageUrl or TemporaryImageUrl, but I couldn't see this particular object as an entity because it is not an object with "critical business rules", but just a simple "auxiliary" object, with very few methods (if any) and I don't think this object meets uncle bob's definition of an entity.

I know that a lot of things are subjective and depend on the context, but this dilemma is very common on a daily basis.

What are these kinds of objects that do not fit as an entity?

Should I always try to find a common ground on my domain and "extract" an entity of these cases?

Could this still be considered as a domain object (even if it's simple)?

3
  • 1
    "simple data holders, anemic classes, are they considered domain objects" - those are not objects in the strict OOP sense, but behaviorless data structures. That is fine, though, but then you'll have operations that manipulate those data structures - so those data structures + related operations (& any additional inputs and outputs) form something roughly equivalent to an entity. With OOP objects, the interface of each object consists of the public methods of the class; in a more procedural style, it's the "top level" functions and their inputs and outputs, and associated constraints. Jul 23, 2021 at 17:49
  • Also, "auxiliary" objects that serve as input and output parameters can be considered a part of the interface (or the API) to a particular entity (or to an aggregate of entities, or to a component, subsystem, etc.) Jul 23, 2021 at 17:52
  • I understand, I can see the problem with anemic objects not being proper OOP, but let's say my object has a couple of behaviors regarding its context, should I consider it an entity? this object also does not fit in a aggregate Jul 24, 2021 at 1:25

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy