(04-12-2015, 02:37 PM)PoEAA: Wrote: A common approach in handling domain logic is to split the domain layer in two. A Service Layer (133) is placed over an underlying Domain Model (116) or Table Module (125). Usually you only get this with a Domain Model (116) or Table Module (125) since a domain layer that uses only Transaction Script (110) isn't complex enough to warrant a separate layer. The presentation logic interacts with the domain purely through the Service Layer (133), which acts as an API for the application.
As well as providing a clear API, the Service Layer (133) is also a good spot to place such things as transaction control and security. This gives you a simple model of taking each method in the Service Layer (133) and describing its transactional and security characteristics. A separate properties file is a common choice for this, but .NET's attributes provide a nice way of doing it directly in the code.
PoEAA then goes on to define a range of Service Layers from a minimal facade layer to a layer which encapsulates most of the business logic for an application, with the latter usually implemented over a Domain Model with an Active Record data source layer. In the middle somewhere is a controller-entity style sometimes implemented in HMVC.
I think it's an interesting idea for an addition to CI, but I'm not sure how popular it could become without some significant improvements in CI's Domain and Data Access layers, especially since it has a wide range of valid use cases and can be easily implemented without specific support from the framework.
