Adding EF Core/ORM to API Layer

Question

We are talking about implementing Domain-Driven Design at my company, which sounds like a great step forward for us. That being said, I am left with a few questions after a couple of days of research. For reference, we are using a model that has: data, business logic, API, UI.

The biggest gap in my understanding is how to define the difference between the business layer and the UI layer. When I see the proposal laid out by the developers, it reads to me like we are making decisions based on the UI, which seems to be against the principle of DDD. They explained to me that I should think of the objects the UI needs as separate business objects. That didn't sit right with me, because it was essentially saying that any change we make in the UI with data(which is fairly often right now, as we get customers feedback) means we need to go through and update 3 layers always, and sometimes up to 4.

And thinking about that is what sparked me to ask this question. Why wouldn't we have direct EF Core access in the API layer, and then if we need to perform any business logic, send the data to a microservice(or business logic function) to get whatever needs to happen to it done. We have clear pieces of logic that exist in the business that aren't just creating a seemingly meaningless abstraction layer, that also needs to be used with different sets of data.

I get the idea behind abstraction for classes in code, but it seems to me like what the API layer is doing is filling the implementation layer for the code to use. It seems redundant to go back and create a second layer of abstraction, especially when it will mirror the first.

• user3347715: I think I need some more clarity on for what the "proposal laid out by the developers" is advocating. It's not uncommon, upon needing additional data as part of some use-case for example, that such a change in the business logic would require a change in your database (maybe adding a field) and also permeate up to your UI. Depending on what kind of system we are talking about here, it's reasonably likely that the impetus for a new use-case could stem from UI-related concerns...
• user3347715: ... What I'm saying is that the order in which you update your code doesn't necessarily reflect the dependency structure of that code. That's more of a matter about developer work-flow and/or project coordination than system architecture. Second, I would expect your API to have direct access to EF Core in a system following DDD. Your API's job is to gather the data necessary to coordinate the fulfillment of each use-case...
• user3347715: ... As for the "business logic", DDD asks that you segregate it entirely from everything else -- so no conducting logic in the API, instead delegating to separately-defined (testable!) functions/objects (thin Controller, fat model). What are they proposing the UI is to be consisted of? The same functions/objects as your model?

Answer 1

The problem you describe is inherent in any layered architecture. You either split by business function or by technology, you can't really do both. So if you split by technology (what "layered architecture" does), you'll more likely end up with having to modify multiple layers when you want to modify business things.

DDD prefers layered architectures for some reason. This is in the Blue Book itself. So I guess if you want to do DDD, you're stuck with modifying multiple layers.

However, you could just do what makes sense for your case and not just do something because it is popular. For example you can define objects based on business-related things that have business behavior and UI related things, and even persistence related things, just like you've said.

This is the only way I know, where you can have cohesive business related objects where changes stay mostly localized.

Summary: You're right, don't create superfluous abstractions, don't use things just because of hype. You can mix UI, persistence and business logic if it is a cohesive mix.