Clean Architecture: Sequence Flow Among Frameworks

Question

I have been trying to learn more about Uncle Bob's Clean Architecture from blogs, article, and videos.

If I were to use a database in this architecture, then what should the UI (as a framework such as web or form) know about the database? Or more generally, how should data flow between two or more pieces/parts that are in the same layer?

For example, The UI would talk to my adapter(s)/gateway(s) to interact with the business entities. To Read/Write, I can see that the UI could call whatever class/classes that can access the database and pass in the adapter(s)/gateway(s), so that it can interact with the business entities.

    public class SomeUI
    {
        public static void Main(string[] args)
        {
            SomeAdapter adapter = new SomeAdapter();
            SomeDataAccess db = new SomeDataAccess();
            db.Save(adapter);
        }
    }

    public class SomeDataAccess
    {
        public void Save(SomeAdapter adapter)
        {
            //Interact with database
        }
    }

    public class SomeAdapter
    {
        //properties
    }

Many of the articles barely vary off of this one (https://subvisual.co/blog/posts/20-clean-architecture). I have not found a good article that covers how pieces that are in the same layer should work with each other. So, articles referring to that would be an acceptable answer.

This does not appear to violate the Dependency Rule, but it feels like I am not doing something right, since I am making a dependency between my UI and database. I believe that I may be over-thinking the concept, and I believe it may be from hammering away at learning the 3-tier architecture (UI -> BLL -> DAL).

Answer 1

You ask:

If I were to use a database in this architecture, then what should the UI (as a framework such as web or form) know about the database? Or more generally, how should data flow between two or more pieces/parts that are in the same layer?

There is no such term as UI component in Clean Architecture. In Clean Architecture terms, the UI would be the presentation layer or the delivery mechanism, decomposed in the following components:

• The view model generator (or the presenter to use Uncle Bob's terms), which is in charge of encapsulating the business rules for the UI. This should access the business model in order to generate the view model from it. The business model is passed to the presenter's method inside the interactor response object by its caller, the interactor.
• The view model which holds data for the view and passed to the view indirectly via for example an event.
• The dumb view which is now decoupled from the domain model and all layers, displays data of the view model.

Decomposing that this way insures better testability, better SRP and more decoupling with application, domain and infrastructure layers.

So your presentation layer should know absolutely nothing about the infrastructure layer.

---

Maybe you got confused by examples using some kind of Web Form component/library? This kind of component propose interconnected functionalities each in relation with several architecture layers: domain, application and presentation… So Web Form components are particularly delicate to adapt satisfactory in a Clean Architecture. Due to this inflexibility, I'm still struggling figuring out what is the best way to integrate a Web Form component in my Clean Architecture implementations...

---

Finally, to make it clear, you said:

For example, The UI would talk to my adapter(s)/gateway(s) to interact with the business entities. To Read/Write, I can see that the UI could call whatever class/classes that can access the database and pass in the adapter(s)/gateway(s), so that it can interact with the business entities.

It's not UI's responsibility to interact with your entities but as its name suggest it's interactor's responsibility (interactor = use case). Interactor are meant to encapsulate application business rules, they represent the application layer. They can CRUD your entities via the Entity Gateway which is your adapter to the infrastructure layer which could be an ORM, a REST API or whatever...

---

Edit #1:

Since a picture worth a thousand words here is Uncle Bob's UML class diagram representing the structure (and the data flow between the concerned components) of the Clean Architecture:

---

Edit #2:

It seems to me that your representation of the flow of control in a Clean Architecture is kind of reversed. Taking as reference the above diagram and Uncle Bob's analogy:

If you don't want your code to be dependent of a thing, make this thing a plugin.

(Said otherwise, make that thing the client of your code that you want independent from it.)

In a Clean Architecture, you want the presentation layer, or more contextually, the delivery mechanism (Controller + Presenter + ViewModel + View) to be a plugin of your business layer (which is composed of components on the right side of the communication channel boundary).

Answer 2

I have been doing more research into other examples of clean architecture.

(source).

From the diagram above, it looks like App (business entities and use cases) talks back and forth with Delivery (Externals: UI). The Delivery is used to talk to External (Externals: DAL).

Delivery is where you implement the delivery mechanism of your application itself. Delivery is where your app is integrated with external data sources and shown to the user. This means in simplest terms the UI, but it also means creating concrete versions of the external objects, such as data jacks, and also calling the actions of the app itself. -Retro Mocha

So, that leads me to believe that yes the code example at the top is valid, but I am still open to hear if anyone else has more to provide on the answer.