1

Suppose I need to register user in my system.

Buisness rules are:

  • email shoud be unique (a kind of identity);
  • name shouldn't be blank.

It looks like I need Service for it.

Probably something like that:

public interface RegistrationService {
  bool Register(String email, String name);
}

And it's fine until I have to return failure reason to user. How to deal with it?

I can see few options (but I don't like any of them):

  1. Implement a kind of result object:

    public interface RegistrationService { RegistrationResult Register(String email, String name); } public interface RegistrationService { bool Succes(); Error[] Errors(); User NewUser(); }

It's fine, and even could be useful for example for REST api. But isn't it too cumbersome(especially considering that blank name probably should be checked at factory)?

  1. Throw exceptions

    public interface RegistrationService { void Register(String email, String name) throws RegistrationError; }

It looks a bit more accurate. But exception are expensive. Using them like this is looks like bad idea.

  1. Use DB constraint. But it looks even more messy than (2).
anoam
  • 127
  • 1
  • 7
  • Error description is an application/UI concern and shouldn't have to do anything with your domain. Throw exceptions in your domain, catch them in the application layer and convert it into something usable for the user – Tseng Feb 13 '18 at 20:35
  • @Tseng, do you mean the second variant? – anoam Feb 14 '18 at 06:02
  • Yea. And exceptions aren't expensive, only if you have to catch them. If its a webservice/restapi you already should do some input validation (of course w/o business logic involved) and don't even call the domain when the input validation is wrong. Exceptions are there when something slipped through the input validation or when it can't be done there (cause business logic or database input is required) – Tseng Feb 14 '18 at 06:56

2 Answers2

1

let's start with point 3: DB constraints get their job done. Yes, the exception/error message is messy, I agree about that. But ask yourself: What is more messy: a terrible error message shown to 1 user or 2 user accounts with the same email adress that can corrupt your system? The DB constraint should be your last safety net. Your service needs to check if a user account with this email already exists. But what happens if in another thread somebody creates a user account with this email in the microsecond between your check and the creation of the new user account? You'll be happy about the DB constraint. Yes, you could find a better solution, but that would require you to have a singleton service that serializes all account creation and makes sure that no two threads can create a user account at the same time.

Point 2: Exceptions are for exceptional situations. The situation that somebody wants to create a user account with an already used email is an exceptional situation. Don't be worried about costly operations in situations where somebody wants to do something dirty.

Point 1: I don't like this. But that's just my opinion. There are situations where a Result Object of this kind makes sense, but I try to Keep it to a Minimum.

EasterBunnyBugSmasher
  • 1,507
  • 2
  • 15
  • 34
  • I just meant it messy, to catch constraints exceptions in app / interface layer. At least for described goals. – anoam Mar 12 '18 at 07:26
0

Different layers can have different ways of considering and signalling a problem. Just because the Infrastructure raises an exception doesn't mean every other layer should do so.

You could have :

  • Infrastructure : throws duplicate key exception, because clients are not expected to threaten the DB's integrity
  • Application: catches the exception and returns a simple RegistrationResult.Failure value, because it's an expected failure case
  • Presentation: returns HTTP 409 conflict
guillaume31
  • 13,738
  • 1
  • 32
  • 51