Concerning Business Objects

[Terence McGhee]

From my understanding of ep 7, in a Clean Architecture's use case there are two types of business objects for each corresponding data structure.

For example, an Employee entity could have:

1. the data structure that represents the database table.
   
   
2. the general-purpose business object with application-agnostic data and methods that either contains or extends the data structure and can be used in any application that requires an Employee.
   
   
3. the domain object that extends (or wraps through aggregation) the application-agnostic object with application-specific data and methods and is meant to only be used in the current application.

Is this correct? My understanding is a bit fuzzy when it comes to object 3 above and the actual Interactor itself. At times it seems like the Interactor is object 3 and at other times it seems like the Interactor uses object 3 (and other objects similar to it) to accomplish its goals.

Thoughts? Input?

[Breno Sarkis]

Nice question!

The way I understood it, object 3 is the interactor.

It'd probably have an 'execute' method that'd make use of the entities it relates to, to produce application-specific behaviour. The question that raises up in my mind is whether it would be 'correct' to use multiple objects to accomplish a single use-case.

[Jop van Raaij]

My understanding also is the interactor has the application specific behavior. Your remark on the aggregated objects makes me think again. I think you have a point, there could be more complex aggregated objects which are only bound to one application. These objects could contain logic and should be combined with the specific application. I'd think this scenario is highly unlikely, unless you have very generic objects, like User and applications with very little overlap. The User object will have very little logic and data, which makes them more widely usable, but also less useful. When wrapping the User object for two unrelated applications, it might be better to use a separate User object for each application. The inheritance or wrapping of the User creates extra dependencies you'll have to maintain.
For each object you have to ask yourself it is worth to create a generic version, usable in multiple applications.

The interactor interacts with business objects, but also with other interactors. Some interactors solve a simple usecase, where others might solve more complex usecases by combining multiple interactors. A simple usecase would be SaveEmployee, or SaveCompany. There might be an ImportData usecase which uses these simple usecases to import a list of employees/companies.

[Uncle Bob]

The way I have defined it, it is the interactors that contain the application specific business rules, and the entities contain the application agnostic rules.  The database table is on the other side of the database boundary and is unknown to the entities or interactors.  

That last sentence needs some explaining.  The gateway may indeed pass a data structure that looks like the database table across the boundary to the entities and interactors.  However, the entities and interactors do not know that this data structure came from a database table.

Now for the interesting part.  Some of the relationships between the entities can be application _specific_.  As such, these relationships will be known to the interactors, but not to the entities.  This can be implemented using subclasses, decorators, visitors, Extension Objects, or any of a batch of other patterns and solutions. 

[Jean-Francois Dube]

Regarding relationships between entities, at some point if you have an Employee entity, a Business (as for corporation) entity. 

Both are different entities and both have an Address property which would probably be an interface containing getters (getCity, getZip, etc)

Would address be an entity too or just a duplicated interface placed in both Employee and Business components ? and in which components would you place it ?

[featurefabrik]

I think you should consider the meaning of "Address" in your specific application.

As far as I read your post, you have to points made. The first is about the duplicated interface of the address attributes and whether it is a good idea to share it in a separate entity or not.
I learned in a really long and painful way that duplication of code is not always particularly bad.

It could be, that Business and Employee share the same address attributes in the first iteration of your application. But what if the requirements for an employee address change? Additional attributes are required or existing attributes must be renamed or deleted. This would be bad, if the same address entity is used throughout the application. I always try to consider what possible changes would break my entity model.

The other point I see is the question whether employee and business should get their own address entity or just attributes on themselves (like city a.s.o.).
I would definitely use separate entities forhousing the address attributes (perhaps an EmployeeAdress and a BusinessAdress entity). This gives you nice separated objects for all the awkward requirements that can occur around addresses.

I hope, I got your points the right way :)