I'd argue most software and domain logic is written using Transaction Scripts. Transaction Scripts are single procedures that handle a request. While this can work fairly well in a lot of cases, it starts falling apart when you have a lot of domain complexity and/or a lot of various concerns. A sign you've gone too far is difficulty testing and wanting to call a transaction script from another transaction script. When this happens, what's a solution? Encapsulating your domain logic and state changes within a Domain Model.

🔗 EventStoreDB
https://eventsto.re/codeopinion

🔔 Subscribe:    / @codeopinion  

💥 Join this channel to get access to source code & demos!
   / @codeopinion  

🔥 Don't have the JOIN button? Support me on Patreon!
  / codeopinion  

📝 Blog: https://codeopinion.com
👋 Twitter:   / codeopinion  
✨ LinkedIn:   / dcomartin  
📧 Weekly Updates: https://mailchi.mp/63c7a0b3ff38/codeo...

0:00 Intro
1:46 Transaction Script
3:31 Added Complexity
5:32 Heuristics
6:46 Domain Model

#softwaredesign #softwarearchitecture #domainmodel