Domain Layer

The inner circle contains the domain model. The domain model consist of entities, attributes, relations and accompanying business rules (e.g. calculations, derivations). The entities and business logic are the least likely to change when something in the external interface or in the page flow changes. The domain layer does not contain any presentation specific logic. Since the domain layer contains the majority of business logic it is important to keep it clean and decoupled from the rest of the application. You do not want to make business logic dependent on external factors such as data base technologies.

Studio uses the following elements for the domain layer:

Entities	Business Rules
Entity	Value list
Attribute	Validation rule
Relation	Expression
Static instance	Decision table
	Business rule
	Rule group

Anti Patterns

"God" model

One big domain model which supports every application results in maximizing coupling. The advantage of such a model is that all information that you might need is always there and ready for use. For example when the result of a calculation is needed, the complete calculation is added to the domain, giving access to all the sub-results which might come in handy later on. For these reasons, it is tempting to create such a model. It certainly gives quick results early on. However, by being able to refer to any piece of information at any time, it becomes unclear what parts are touched when changing a single small thing. Hence, the application will be hard to maintain in the near future due to unwanted ripple effects, unmanageable regression effects and hard to understand models.

Source: Wiki "God model"

Domain model dependent on Database

When creating an application that reads or alters entries from an existing database, it is tempting to copy the structure of the database so that all information can be written and read in a straightforward manner. The domain model should however not be dependent on the database. When the database changes its structure or if another persistence technology is selected this has a major impact on the domain model, as the defined domain is not 'valid' anymore for the database.

The domain layer should not know anything of the database. There should be a service in the application layer that maps the information of the domain to the database. When the database changes, then this service needs changing as well, but everything from the domain layer can stay untouched.

Mixing custom code with domain model logic/manipulation

There are many functions available that allow you to derive values. If some complex function is needed which is not present out-of-the-box, then custom code in the form of a service call may help out. Mixing custom code and declarative models will result in difficult maintainable models, if the business engineer does not exactly know what the service call changes in the model and if the dependencies can not be visualized.

When you understand all the layers, go to 3. Clean Architecture in practice or have a look at Business Rules and the Clean Architecture.