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.

3 Answers 3


enter image description here

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.

  • I would argue that even if you re-pack a data structure into a different data structure you still have to know the same things. Sure, you've eliminated a direct physical dependency, but logically you're still using the same knowledge as previously. What data elements are there, how they're related, what they mean, what validation you have to use, what logic to fill them out, etc. The UI still stays very tightly coupled to details of the domain. Apr 22, 2020 at 10:15
  • @RobertBräutigam nope. The UI knows how to display abc. If the domain decides to model xyz the UI doesn’t care because the presentation layer knows how to turn xyz into abc. Apr 22, 2020 at 15:59
  • The UI knows how to display an Amount for example. It has to know what an Amount is. It is a value and a currency. Has to know what a currency is. Has to know that a currency has influence on the Amount as far as comparing or even displaying. Has to know how precise the value is, what precision even means in this context. Has to know whether negative or positive values need to be displayed differently. And so on and so on ad infinitum. Displaying something is a very intimate action that needs intimate knowledge of the thing displayed. All that for input too plus validation. Apr 22, 2020 at 16:34
  • @RobertBräutigam the UI has to know every pixel to display that amount. Has to know how many. Which are on. Which are off. It doesn’t have to know what a single one of them means. Apr 22, 2020 at 18:51
  • @RobertBräutigam the UI has to know every button you pressed and when you pressed it. It doesn’t have to know what pressing that button does. Apr 22, 2020 at 18:56

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.