107

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. ...


54

When different people talk about decoupling the UI from the business logic, they sometimes mean different things: They can mean not to implement any UI independent logic inside an UI layer - all logic which can be useful outside an UI should be placed somewhere else. Your example shows such a case. CanUserInputPromoCode may be useful out of the UI, or at ...


39

You need to be clear about what is meant by business logic. Business logic refers to the logic that act on the data. It is not logic that validates the data. It is not logic that reacts to the data. It is not logic that displays the data. Showing a list differently if count is 0 is not business logic; it is presentation logic. Ideally, it should not be ...


22

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 = $...


17

And knowing (correct me if I'm wrong) that a repository shouldn't return a DTO Theoretically, every layer (= project in your solution) should have its own DTO objects. In that sense, your repositories should return a DTO, but this is not the same DTO as the "business logic DTO". However, in reality, we don't need that much separation. The benefits do not ...


15

Layers, Onions, Ports, Adapters: it's all the same Since this article makes clear that onion is equivalent to 3 layer + application of the Dependency Inversion Principle (DIP), then the question becomes "where should I prefer to use DIP?" I'd say any non-toy project. Using DIP allows the core of your code to be more isolated, testable and maintainable. When ...


15

My guiding principle here is to ask what I consider the most important design question: What knows about what? Here's an onion diagram. It's not that much different from this: But this one shows the flow of control in and out of layers. Note the purple arrow in the lower right corner. That's important here because the flow of control dictates the order of ...


14

It seems to me that most 'new' things in software architecture are old ideas refurbished and combined with new technologies or other ideas. Often these are incremental. In this case, the change that I think matters is the database is no longer the center of the design. This is not an minor change; it's pretty fundamental. So is the "onion architecture" ...


13

You can't separate a UI from logic, but you can separate most to all of the "business" logic. Conditional rendering is fine, and you don't really need to involve business logic to do it. Rather than checking item count in your example, you could reference a "promoVisible" boolean. The DTO exists to transfer data, part of the data that ...


9

Q: Do you always expose a service such as IUserService to an app that consumes it? We usually do. Some times by inertia (we got used to), others for testing, but most of the time to decouple boundaries within the application. It's a common practice which brings us interesting benefits at a small cost (complexity). Services orchestrate calls between ...


8

Overview Let's step back a little, and look at the original Onion Architecture proposed by Jeffrey Palermo. The outside skin is the interface to the external world: the user interface, the test suite (the idea is to promote TDD alike systematic tests for everything inside), and the infrastructure. Then you dig deeper inside towards the core to find ...


7

Domain Layer should only contain Business Logic. This confuses me when I read about the Onion architecture, which states that the domain layer should contain all interfaces including services and repositories Business Logic is the core responsibility of the domain layer. However, if that was strictly all the domain layer knew about, it wouldn't be able to ...


6

There is nothing at all required of you from a project/folder perspective to establish an Onion architecture, though the layers in the model do suggest natural places to put project/API boundaries. Take a look at this diagram: Now have a look at this one: Other than the shape of the diagrams, do you notice anything interesting? The only material ...


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, ...


5

I'm not so sure that the onion architecture makes much sense in this case. What you can keep from the onion architecture is the principle that your application core (the translators) should be decoupled from the data access. But overall your requirement is much more like a pipeline. read -> transform -> write Now, read and write are impure (...


5

Use case containing the presenter or returning data? So, is any of these two alternatives the "correct" interpretation of the Use Case Output Port according to the Clean Architecture? Are they both viable? In short Yes, they are both viable as long as both approaches take into consideration Inversion Of Control between the business layer and the ...


5

What you are looking for is called Bounded Context in DDD. Now, as you are realizing in your question, bounded contexts might share data. The best way to implement it that I saw is simply to duplicate the entities. So Accounting context has Customer, and so does Production have Customer. But even though they have same name, they have completely different ...


5

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 ...


5

I've read that Domain Services are services used by the domain model ... In DDD, domain services are part of the domain model/layer. They encapsulate business logic that doesn't neatly fit into a single entity in the model. A classic example is BankAccount (entity) and FundsTransferService (which operates on two accounts at a time). ... and Application ...


5

The core argument for using repositories is to prevent leaking EF dependent code into your domain. That argument is not wrong, it just comes with a steep cost, i.e. a high-complexity uow/repo layer, which is now being regarded (by some, at least) as too high a price to pay for what it gives back. By not using that uow/repo layer, you do actually let your ...


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

You apply DIP when crossing a significant boundary. What's on either side doesn't matter. What matters is having a good reason to keep what's on one side from having a source code dependency on the other side. The magical thing DIP does is let you enforce that source code dependency rule while allowing flow of control to go in and out of that boundary ...


4

Onion architecture means hiding dependencies to infrastructure behind an interface. All components that use IUserService do not need to know wether the service is implemented using soap, rest, http or anything other infrastructure related. The actual UserService implementation uses a repository interface IUserRepository as implementation detail. The ...


4

By adopting DDD and onion architecture, you have decided that database is second to your domain model. That means, there won't be anyone else doing operations on the database other than the model. If traditionalists don't like that, they should have objected to use of DDD in the first place. First thing is clear : you need the "lookup table" in the model. ...


4

The Unit of Work is the transaction. The challenge is making sure the NHibernate interfaces and classes are not referenced outside of your data access layer. The unit of work interface should not have any NHibernate references, something like: public interface IUnitOfWork : IDisposable { void Begin(); void Commit(); void Rollback(); } The ...


4

Are Services part of the Bounded Context? Yes. Contexts separate areas of potentially different meanings, and they cover the whole application completely, there is nothing "outside". What might be confusing is, that Services are actually not part of the Domain. You might think, that Domain-Driven Design is all about the Domain, but for some reason Eric ...


4

Firstly, there is no such thing as a "best practice" architecture. There is only that architecture that best fits the specific need at hand. We're doing a great disservice to software developers new to our industry by continuing to teach a vocabulary-based, syntax-based "pattern-based, best-practice" style of development without explaining why all of ...


4

Yes, it’s possible. The light bulb went off for me when I realized that “business rule” is not synonymous with “if statement”. You can have conditional rendering without specifying why the element is rendered (or not). The shopping cart can have zero or more items and the promo code input can be included or not. From the UI’s perspective these are two ...


3

There are some good answers here already. As it has been said, Clean Architecture's presenters exist to decouple use cases and views. It's worth noting they are not exactly the same as prescribed in the MVP architecture. I'd like to add that you can use the option #2 (use case to return data) and still implement presenters as described by Uncle Bob in his ...


3

Spring Framework is a framework that supports both architectures. It has features to make database-centric architecture easier to do, but it would be a misnomer to simply classify it that way. There are several microservices built with Spring that don't use a database at all. You probably don't know about them because they are proprietary to, well, a ...


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