In a layered architecture, is a domain object sent 'up' to the ui layer so that the ui layer can display the fields that are in the domain object?

Question

I'm learning about the Layered Architecture Pattern for Software Development but I'm confused on how objects are sent 'up' the layers. In general, I know that there are about 4 main layers: ui layer, use case layer, domain layer, data access layer.

So now, let's say I am developing a use case to display all todo items from a todo list on the screen. My domain would have two classes: TodoList and TodoItem. The TodoList class will have a list of TodoItems and the TodoItem class will have a description attribute. Both these classes are created in the domain layer and 'only' the use case layer has access to the domain layer. So, the use case layer will call on the domain layer to get the list of todo items. At this point, will the method getTodoList() return the 'TodoList' object defined in the domain layer back to the UI layer?

If this is correct, then the UI layer would have access to the domain layer object which in my opinion breaks the layered architecture pattern because now the developer can further call directly to the domain layer of that object.

I'm confused at this part and would greatly appreciate clarity on how objects are passed down and up the layers of the layered architecture pattern.

Answer 1

In a Layered system each layer depends on the layers beneath it. A layer should have no knowledge about any layer above it.

thinktocode.com - layered architecture

You called it UI, they called it Presentation but other than that discrepancy this diagram and that rule both allow a domain object to be understood by the highest layer.

I can tell that it's bugging you anyway. And it should. But violating Layered Architecture isn't why. No this is a different rule.

The violation here is against the Law of Demeter. I prefer to call it the Principle of Least Knowledge. It basically argues against being overly familiar with everything. Talk to your friends. Not friends of friends.

Any object that is intimately understood by layer after layer represents an easy way to break layer after layer.

The UI should have it's own data structure. One that doesn't know or care about the domain. One that a presentation layer could populate from a different data structure. If doing that sounds like a lot of extra work that's only because it is. You don't get flexibility for free.

Answer 2

A common way people avoid what you describe is to re-pack everything into different data-only-objects on each layer boundary (introduce TodoItemDto an such things). These new objects usually look very similar to the objects they are created from, to the point where there are actually tools to automatically copy data back and forth. This doesn't usually bother people for some reason.

What you need to keep in mind though, is that the Layered Architecture is not an object-oriented architecture pattern, it is a procedural one. It argues for keeping the procedures separated (i.e. "business rules" in the domain, presentation logic in the ui layer), but sharing the data promiscuously to make this work. It asks for objects to be broken up horizontally based on technical details rather than vertically based on business functionality.

Answer 3

Layers are abstract concepts. We can build that cake in different ways and the analogy with "physically touching" does not go very far.

The most simple way to separate layers is functions from one layer calling functions one layer lower, which in turn call functions in the layer below that and so on. Until a function returns a result (or is just done) and returns to the caller, thus making results bubble up the call stack. Everybody understands this. But modern computer software is more intricate than this. We have threads, we have events, we have actions, we have networks, we have right management on multiple levels and what more.

The point of layering is not to avoid that one layer can touch another, it is primarily to separate concerns and thus provide maintainability. There are other ways to make it safe in whatever regard. In a well layered system you can have a developer mess with one layer without making the system fall apart in another layer and it allows you to talk about the system in abstract terms. That is all there is to it, you should not make more of it. Hierarchy is not everything.