The most outside layer prevents external components to enter into the application and domain layer which contain business logic and behavior. This layer is where all the details go. The Web is a detail. The database is a detail. These things are kept on the outside where they can do little harm.
Some elements in the interface layer are
- User Interfaces (webbrowser, Mobile apps); E.g. Input validation, no logic to save data, input fields, buttons. User Interfaces do contain logic but only for input validation.
- Functions exposed within the Blueriq platform (Blueriq as a service)
- Functions exposed to external systems (e.g. REST/SOAP services, adapters for translating messages into the application message format)
- Persistence of data; Data persistence is not the center of an application but it's external.
Studio uses the following elements for the interface layer:
| Domain | Interaction | Connectivity | Configuration |
|---|---|---|---|
| Entity | Page | Service call | Blueriq as a service |
| Attribute | Container | SOAP service | |
| Relation | Button | REST service | |
| Validation rule | Text item | ||
| Content item | |||
| Image | |||
| Validation types |
Patterns
Mapping for external data services
HDN messages (https://www.hdn.nl/) are a data format for exchanging mortgage information in the Netherlands. It uses attributes that you might not need for your application, or want to name or structure differently. In order to keep this separate from your domain layer, you should create a separate module and use a Data mapping to transfer information from and to this different format. Your domain layer should not care about the structure in which information is send or stored in the outside world.
Anti Patterns
Input validation mixed with domain layer
Validation rules are part of the interface layer. They should validate the input, and nothing else. Once the input is valid, business rules can take over in the domain layer. As an example, a violation rule that indicates that a user should be at least earn 2000 euro a month for renting a house. This rule mixes the domain layer into the interface layer, as the amount of 2000 is a business rule. It is better to create a boolean attribute Person.EarnsMinimumSalary and use that in the validation. Then a business rule in the domain layer can set the value of this attribute.
Only "comfort logic" is allowed in user interfaces such input validations, business logic for flowing or some basic decision making. Examples of comfort logic are simple input validations such as the correct date or phone number format, an IBAN check, or if a field is required. Anything that is complex and which is determined by the business should be placed in the domain layer.
Mixing external interface components with the application layer
Mixing external components and or systems (e.g. databases, response messages from external webservices) with the application layers should be avoided. By letting external systems into the application layer an unwanted dependency has been created. See the example in Chapter 3. Clean Architecture in practice.
Entangle domain, application and interface attributes
As all three layers use entities, attributes and relations, those are quickly mixing. There will come a point at which it is not clear any longer in what layer an attribute belongs. Try to separate them, as shown in the Mapping for external data services pattern.
When you understand all the layers, go to 3. Clean Architecture in practice or have a look at Business Rules and the Clean Architecture.
Overview
Content Tools