The Stack Overflow podcast is back! Listen to an interview with our new CEO.
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 ...


10

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


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

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

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


5

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


5

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


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


4

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


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

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

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

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


4

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


4

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


4

Dependency injection and the decorator pattern are your best friends for doing A/B testing. My team has several experiments running at any given time and we maintain a single codebase for all of them. The general idea is to define an interface for every piece of logic that you would like to A/B test, and create: a production (control) implementation with ...


3

The Clean Architecture does not say anything about implementing interfaces, dependencies or interactions between different use cases. Use cases are all part of the same ring. So at this part of the system, you are on your own, have to start thinking by yourself and make your own decisions about how you are going to implement things in a meaningful manner. ...


3

Your question touches on multiple issues. I've tried to decouple them as best as I can. Direct answers to your questions Is validation logic actually business logic and if so is it wrong to have validation logic anywhere outside the Core project? This does not feel correct because this means that all requests will pass to the Use Cases unfiltered (and I ...


2

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


2

I think it's a great question and something I've been thinking through as well. The approach I've been taking is: First address the domain objects. In the chess world, you'll probably have a Board and a set of Piece objects. The Piece object has concrete classes (e.g. Rook, Queen, Pawn, etc) that inherit from a generic piece (e.g. all pieces can move on a ...


2

The point of the Clean Architecture is to make technology in the application easily replaceable. This comes at the cost of making changing business logic expensive. So if you are doing an application in which changing business logic (i.e. delivering business value) is more likely than changing technologies, then I would suggest to just ignore the Clean ...


2

Note that even if you don't "implement" an interface, the public members of your class form an implicit interface. I had my doubts and did some testing. (Martin explicitly used Java for his example, so I did as well.) Even without any interfaces any change in OPS does not cause any user to be recompiled. This is true only if you did not change the public ...


2

We have something else like an actual God Service. The entire backend is accessed from the frontend by a single interface of 15 or so methods, all of which take Stream as argument (because it really is remoting to another process). Now, the stream API is ridiculous to code against, so we did that exactly once. The service object is this single object that ...


2

Requirements My application requires a user to do a test. A test consists of a collection of questions that a user needs to answer. An audio file is played for every question. After the test, the user is provided with a test result. The Use Case Based on the requirements above, there would be only one use case: do the test. And, so far, one actor: ...


2

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


2

True. The boundary interface between controller and interactor is not really necessary. If it was not there, the dependency direction would still be correct. If I were to speculate I would say the boundary interface between controller and interactor is there just for sake of symmetry. As the other boundary interface is necessary to invert the dependency. ...


2

Answer Based On Comments With the provided update, User entity is something that can hold some implementation of Credit Card, whether it be Stripe or whatever other external thing that is outside of your system, so any unique identifier in this context represents both User and Card combined instead of uniquely identifying some User or some Card exclusively. ...


2

If you're only holding data in your Entities your domain model will become anemic, because the encapsulation is broken and the behaviors are all defined outside the entity, far from where the data are declared. The whole point of the Clean Architecture (and the Hexagonal Architecture, Onion Architecture, etc.) is to promote the Dependency Inversion ...


2

You had an error, and you received an error message that described in some detail what went wrong. Nice for you. But what are you actually doing with it? When you have an error message, you may use it to fix the problem at runtime (are you doing that?). You can somehow show it to the developer ( through logs, or directly if the developer runs the code) to ...


2

The very definition of the terms "front end" and "back end" comes from the separation of business logic (back end) from the user interface (front end). So yes, business logic should be in the back-end, whether that is a remote service or simply a different layer in the same application. Given that you already have a separate back-end system, you should ...


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