1

Let's take a hypothetical system, a state based, exceptions thrown from persistence layer or other outer layer, should propagate to ui layer through domain layer. Domain need not know about this exception. so no catching(ideal domain?)

the issue is that the outer layer catches the exception, but now the system is in some weird state. and to fix that the ui needs to call some magic routine/function on domain which fixes the state of the domain.

but if we are providing this routine to outer scope. why can't we just catch the exception in domain and so we never get into the wrong state. but that means domain needs to know about every exception that can be thrown.

question is, is it domain's responsibility to catch the exceptions? but i don't want my domain code to get bloated with catches everywhere which is kind of same as with Result Type...

i know exceptions should be exceptional and one should use special pattern, like Null Object when he/she knows no value is a valid case. But that's not always true. Also, the wrapper around the library, should be able to catch exceptions but that's not the case always and exception should be propagated, till it finds a suitable point where it can be handle. the other outer layer, mostly ui or log file.

idk, if this fully makes sense, and if it doesn't please correct me and guide me to what i am missing...

3
  • 5
    It would be way more easier to answer such a question when it would contain a real-world example instead of a vague, hypothetical description.
    – Doc Brown
    Jun 7, 2022 at 20:10
  • This question seems to boil down to "why should you ever throw an exception more than one level up?", you're going to find a fair amount of prior discussion on that topic of where to catch exceptions and why there.
    – Flater
    Jun 7, 2022 at 20:34
  • why can't we just catch the exception in domain and so we never get into the wrong state. but that means domain needs to know about every exception that can be thrown. Well, looks like you are missing the "business" layer. It's the immediate layer after the domain and the one deciding whether an exception is a big deal or not. The domain model's main responsibility is to ensure the invariants in-memory, not in the file system or in remote stores/systems. The business layer will take care of these things along with the rest of the perimeter layers.
    – Laiv
    Jun 8, 2022 at 8:00

2 Answers 2

2

If you‘re using concentric architecture models such as hexagonal architecture, onion architecture or clean architecture, the inner cores (e.g model) should not depend on outer cores.

However, interfaces may be used for the purpose of dependency injection. And if the interface foresees potential exceptions, these must be known. So indeed, the model may know interfaces from outer cores. The only constraint is that you should only rely on general purpose exceptions that are shared by all the possible implementations of the interface, and not implementation specific ones.

2
  • 1
    To make this a bit more concrete: If you have an interface WhateverStore, its Save(Whatever) method can throw a CannotSaveException. The concrete WhateverDatabaseStore should catch any internal exceptions that happen during saving and wrap them in that CannotSaveException. Jun 9, 2022 at 13:51
  • @JoryGeerts Thank you very much for this more concrete example :-)
    – Christophe
    Jun 9, 2022 at 16:10
0

Let's take a hypothetical system, a state based, exceptions thrown from persistence layer or other outer layer, should propagate to ui layer through domain layer. Domain need not know about this exception. so no catching(ideal domain?)

You sort-of already handicapped yourself by thinking in layers. Although it is a popular thing to do, cutting things up based on technical aspects (~horizontal cuts), as opposed to based on behavior (~vertical cuts), peppers the same thing all over the place.

This might be contributing to you not being able to identify where things should belong, since the same business thing is cut into multiple pieces. It is already in multiple places, so the battle is pretty much already lost.

You can perhaps imagine, if the same business thing, like an Account, has all the necessary behavior to function, including presenting itself, persisting itself, the decision about some exception to keep the account consistent would be pretty easy to place.

Here is an article of mine about Layered Architectures in general and why they are perhaps not the best way to design applications.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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