What approach is there for handling and returning errors (non-exceptional and exceptional) in Domain Driven Design entities and aggregate roots? -


i'm trying find article/examples of how ddd entities treat errors (and considered exceptional errors , wouldn't) , how pass them calling application layer (which wraps operations in transaction need rolled back).

currently i'm thinking consider errors break transaction of aggregate (such validation) exceptions. way can rollback transaction in "catch" block. example:

someapplicationservice:

// start transaction here // ...  try  {     $user = $userrepository->userofid($id);     $user->dosomething();     $user->dosomethingelse();  // <-- imagine error thrown here     $userrepository->save($user); }  catch (customfriendlyforuiexception $e) {     // custom friendly ui error     // rollback transaction , add error/message ui payload dto     // ... } catch (anothercustomexception $e) {     // not friendly ui, use general error message ui     // rollback transaction , add error/message ui payload dto     // ... } catch (exception $e) {     // catch other exceptions, use general error message ui     // rollback transaction , add error/message ui payload dto     // ... }  // end transaction 

is correct approach, or missing something?


Comments

Popular posts from this blog

java - UnknownEntityTypeException: Unable to locate persister (Hibernate 5.0) -

python - ValueError: empty vocabulary; perhaps the documents only contain stop words -

ubuntu - collect2: fatal error: ld terminated with signal 9 [Killed] -