77

The Clean Architecture suggests to let a use case interactor call the actual implementation of the presenter (which is injected, following the DIP) to handle the response/display. However, I see people implementing this architecture, returning the output data from the interactor, and then let the controller (in the adapter layer) decide how to handle it. ...


50

This is not a God object. It seems like it is because there is so much here, but, in a way, it's doing nothing at all. There is no behavior code here. This isn't an omnipotent God that does everything. It just finds everything. It's less a true object at all and more of a data structure. This pattern has a more proper name: Service Locator. It strongly ...


42

While the “Clean Architecture” is fine and has many advantages, it is important to remember that: The Clean Architecture is largely Robert C. Martin's re-branding and evolution of related approaches like the Onion Architecture by Jeffrey Palermo (2008) and the Hexagonal Architecture (“Ports and Adapters”) by Alistair Cockburn and others (< 2008). ...


27

I really liked the concepts in the video The Principles of Clean Architecture by Uncle Bob Martin. But I feel like this pattern is like a combination of Abstract Factory and Builder patterns at its core. Not even close. When you look at this: You are looking at the design of an object graph. This dictates what knows about what. What's missing from this ...


13

Is this correct? Did I understand the clean architecture? If you want to create a solution consistent with clean architecture you have a number of issues. Dependencies should only cross boundaries going in one direction. That keeps the inside from needing to know about the outside. That means the outside can change and the inside won't care. This also ...


12

In a discussion related to your question, Uncle Bob explains the purpose of the presenter in his Clean Architecture: Given this code sample: namespace Some\Controller; class UserController extends Controller { public function registerAction() { // Build the Request object $request = new RegisterRequest(); $request->name = $...


12

In that particular example the use of Java as compared to C++ does indeed hide the benefit of interfaces. Interfaces (or more generally, late binding) are useful to break direct dependencies. Direct dependency Indirect dependency ================= =================== +---------+ +-----------+ | Service | | Interface | +------...


11

You are correct that both focus on separating the domain code from the application and infrastructure code. But that is where the similarities end. In Clean/Hexagonal/Onion (or CHO in short) architecture, the goal of this decoupling is testability and modularity with intended effect being that the "core" of our software can be reasoned about in isolation ...


9

It should be on a case-by-case basis but I would expect most of the logic to go in the backend. Your interactor might still contain several methods ("Check ticket availability", "Add ticket to basket", "Checkout") but yes the implementation could be expected to be very simple in some cases. You might want to consider: Security. Any code that you need to ...


8

I just read the book 'clean architecture' by Uncle Bob and really like the approach. But the big disappointment came when I tried to implement it in C#. I really hope you can help me with some questions. You don't implement Clean Architecture. You follow it, as you implement something else. Even if all you're doing is creating a reference implementation ...


7

If the controller talks directly to the presenter you lose the ability to independently swap out controllers and presenters. They are now entangled. They know about each other. If the controller sticks to talking through an abstraction to something that implements, lets say, a Use Case Input Port, then it neither knows nor cares which presenter displays ...


6

Your observation is correct. However, that does not mean the "Clean Architecture" approach is wrong in general. One major technique to decouple things from "outer rings" like the database layer or network layer from the business logic is Dependency Injection. This can help to make your system more decoupled from lots of technologies except one: the DI ...


6

ViewModel Architecture and Clean Architecture are not the same. In some ways they are incompatible. Please don't mix them carelessly. The number one thing that separates them is cycles. ViewModel architecture is comfortable creating cycles in it's design. Clean (or Onion, or Hex) Architecture is not. ViewModel uses a binder to resolve the problems this ...


6

The central idea of the DIP is to eliminate any direct dependencies between higher-level modules and lower-level modules. To achieve this, an abstract, stable interface is placed between them, upon which both layers depend instead. In the repository pattern, the interface usually references the entity for which the repository is responsible. It therefore ...


6

You are probably trying to generate the JSON error information at the wrong level in your architecture. If you convert data from one format to another at a layer boundary (like going from PersonInput to Person), then you should also catch all errors that come back over that layer boundary and perform a reverse mapping as needed. That is the only way that ...


6

You could use the models created by EF as purely models made for persisting your data. You should map these to an actual Employee domain model class that can hold all your business logic and that would be truly your domain models.


6

ORMs like Entity Framework do not preclude you from using Raw SQL queries. If Entity Framework is a bit too much for your liking, consider using Dapper or any of a number of different micro-frameworks. These tools remove a lot of the hassle of making a connection to the database and managing query parameters without encountering Little Bobby Tables, ...


6

Perspective Rub your eyes and look at what you are discussing: a WebApp and a Server that communicate across a network. That is literally two separate applications with a network interface. In fact you have just reinvented the Thick client. Just instead of installing it on Windows, and compiling it from C++ you are writing it in JavaScript and installing it ...


5

To quote the video: "You don't want to do mail merges in SQL." followed by: "I actually saw a SQL stored procedure which was an entire mail merge" The architecture, like mail merges, is just one option among many. What's not optional are the problems which the architecture is trying to solve. If you understand what problems the SQL mail merge ...


5

Looks to me like your issue is: I have a thread acting on behalf of a user. I don't wish to pollute my nice clean business logic with authorisation details. But my data store needs authorisation details to enforce control of the data. From your description it sounds pretty critical that User A does/does not have access to Client B. That sounds very much ...


5

I am using Clean Architecture for a rich desktop application since about a year now and it works well for GUI-heavy, event-based applications. It's not a good fit for a "real-time" game like a jump'n'run, but a chess game will work just fine. Instead of dissecting your question, I will go through a recap of the layers and will end with following the process ...


5

Inject across boundaries. Hard coding matters for testing but mocking frameworks and reflection magic can take care of that. The critical boundary is deployment. If you want units of code to be independently deployable they can't have hard coded dependencies on each other. If you want to change a classes name it sucks if the refactoring reaches into code ...


5

Four things helped me a lot when deploying many features per release, and testing them in production: Feature flags. Whitelists. Routing control. Detailed logging. A feature flag allowed us to enable a feature for controlled time, e.g. a specific part of a day, or in one region only. It allowed us to quickly "undo" a change that did not work out for ...


5

There are places in your code base that:     A) do not know that bookId exists     B) do know that bookId exists     C) know that bookId is really a long Maximize A. Minimize B. Minimize C even more. Not knowing, when you don’t need to know, is a good thing.


5

Is there anything that forces you to handle complex business logic for authorization rules at the database level? I would rather recommend to handle such business logic rules in the application code. Your database can contain information that tells you what roles a specific user has or what groups they belong to but fine-grained rules that reflect what a ...


4

The division of specifications into "Business Rules" and "Application Rules" is always going to be somewhat arbitrary. In the abstract it might seem obvious that the Sales Report is a Use Case and compiling it in the application requires application level logic to manipulate Orders. Where as an Order is a Entity that contains Business logic. But you could ...


4

The Clean/Onion/Hexagonal architecture applies most clearly to microservices when viewing each microservice in isolation. Each MS has its own model and its own use cases and defines its own external interfaces/ports (both for supplying data and retrieving data). These interfaces can be implemented with an adapter that connects to another microservice, which ...


4

While it's true that the controller to interactor boundary isn't helping you invert a dependency, that isn't why it's there. The reason it's there is this: • High-level modules should not depend on low-level modules. Both should depend on abstractions. That's from the Dependency Inversion Principle. All it means is that it's nice to have a stable ...


4

In my view a "use case" refers to a user, using the product. Not an internal implementation detail such as an internal API. so you, presumably, have two use cases as a X I need to see partial data as a Y I need to see full data Your 2 screens fulfill these requirements, one for each. How they work behind the scenes is up to you Example "Use Case" As ...


4

In addition to Mike's answer and in line with the comments above. The business knowledge encapsulated in CalculateReimbursement makes it fits in the core. More specifically, in the Entities layer. Entities encapsulate Enterprise-wide business rules. An entity can be an object with methods, or it can be a set of data structures and functions. It doesn’t ...


Only top voted, non community-wiki answers of a minimum length are eligible