As we've seen before, in object-oriented languages, we often see classes that use the power of polymorphism to keep the behavior close to the state. In functional languages though, the state is usually maintained separately since the behavior can be represented as functions, which manipulate instances of record types that represent the state.

Logically, things like communication protocols, user input validation, and persistence implementation are not being seen as part of the domain model. These are technical and infrastructure concerns. A good rule of thumb here would be that the whole domain model should be testable without involving any infrastructure. Primarily, in your domain model tests, you should not use test harnesses and mocks.

If you look at the onion architecture, hexagonal architecture and clean architecture principles, you will find out that they have one thing in common. The center of any application is the domain.

Application services and infrastructure are kept outside and form layers around this core of the system. Unlike layered architecture, which has dependencies going down from the UI layer to the data layer, we see that the domain is the center of everything and everything depends on it. Such a change, although could be recognized as a small adjustment, has a very significant impact. Instead of everything depending on the data layer, which makes database the master of all, the focus shifts to the domain, making the domain model the most significant part of the system.