In an Onion type architecture, should the entities cross the outer layer?

Question

I've been trying to understand this new kind of architecture which names can be Onion architecture, Clean architecture, Ports and Adapters, etc.

If I take the abstraction of Ports and Adapters, when I adapt my application for a particular port, is it ok for me to give the port an entity from inside my application? Or am I always supposed to adapt the entities also, to fit the port?

Example:

Say I have a Customer entity. I have a UI that uses my application. My UI calls through an Adapter to getCustomerById(123). In turn, my adapter will call through to my application, effectively retrieving a Customer using the injected Repository, and it will perform some sort of formatting on it and logging and what not, once the Customer is ready, it is returned to my UI. My question here is, my Customer object is returned as is to my UI. This means my UI has a reference to the Customer class from my Core project. My UI then goes on using that Customer object to do things, maybe change it's name, etc. and eventually calls the adapter again to updateCustomer(customer).

Is this ok to do? Is it ok that my UI uses the Customer class from inside my application core. Or should I instead adapt my Customer to a new Customer object say UICustomer and have my UI work with that instead, mapping back and forth between Customer and UICustomer at the adapter level?

Answer 1

Great question. I have an example that might be useful. https://bitbucket.org/jeffreypalermo/onion-architecture

For simple applications using the Core domain model objects can be just fine. These are designed to not have nasty tentacles of dependencies hanging off of them, so they work very well and are quite portable. They can travel across the layers without causing any issues.

Answer 2

I too am starting to learn/implement the onion architecture. From what I can tell, your original method (Customer Entity in the UI) is an acceptable practice. Look here for a graphical, linear, representation of the Onion Architecture:

http://jeffreypalermo.com/blog/the-onion-architecture-part-3/

You can see that the UI can interact directly with an underlying Object Model. Since your customer is not a direct DB entity, but instead loaded from an injected repository, this seems to fit the model of the Onion.

My assumption here is that the Customer Entity is really a composite of different, normalized, DB entities which are assembled via the injected repositories.

My understanding is that in principle, the interactions are done through abstractions, and the fact that the Customer Entity is an abstracted representation of the Customer Database, this is valid.

Please, correct me if any of the above assumptions/thoughts are incorrect.