DDD: Function conflict without side effects

Question

I apologize for so many questions, but I felt that they make the most sense only if they are considered as a unit

Note. All quotes from DDD: heart complexity in software (pages 250 and 251)

1)

Operations can be divided into two categories: teams and queries.

...

Operations that return results without side effects called functions. The function can be called several times and returns the same value each time.

...

Obviously, you cannot escape commands on most software systems, but the problem can be mitigated in two ways. Firstly, you can keep commands and queries strictly isolated in different operations. Ensure that the methods that cause the changes do not return domain data and are kept as simple as possible. Perform all queries and calculations in methods that do not cause observable side effects.

a) The author implies that the request is a function because it does not create side effects. He also notes that the function will always return the same value by which I assume that it means that for the same input we will always get the same result?

b) Suppose we have a QandC(int entityId) method that requests a specific domain object from which it extracts specific values, which, in turn, are used to initialize a new Value object, and this VO is then returned to the caller. Does the function above QandC phrase, since it does not change any state?

c) But the author also claims that for the same input the function will always produce the same result, which does not apply to QandC , since if we place several calls on QandC , this will lead to different results, assuming that in time between two calls this object has been modified or even deleted. Thus, how can we state that QandC is a function?

d)

Make sure that the methods causing the changes do not return domain data ...

The reason is that the status of returned non-VOs may be changed in some future operations, and therefore the side effects of such methods are unpredictable?

e)

Make sure that the methods causing the changes do not return domain data ...

Is a query method that returns an object that is still considered a function, even if it does not change state?

2)

VALUE OBJECTS are immutable, which means that, except for initiators called only at creation time, all their operations are functions.

...

An operation that mixes logic or computation with a state change must be reorganized into two separate operations. But by definition, this separation of side effects only into simple command methods applies to ENTITIES. After you finish refactoring the change from the query, consider a second refactoring to move the responsibility for complex calculations into the VALUE object. a side effect can often be completely eliminated by obtaining the VALUE OBJECT value instead of changing the existing state or by moving the entire responsibility in the VALUE OBJECT.

a)

VALUE OBJECTS are immutable, which means that, except for initiators called only during creation, all their operations are functions ... But by definition, this is a segregation of side effects into simple command methods that apply only to ENTITIES.

I think that the author says that all methods defined in VO are functions, which does not make sense, because although the method defined in VO cannot change its own state, it can still change the state of other, -VO objects ?!

b) Assuming that a method defined in essence does not change any state, do we consider such a method as a function, even if it is defined in essence?

c)

... consider the second refactoring to shift responsibility for complex calculations into a VALUE object.

Why does the author offer us only refactoring from objects that perform complex calculations? Why should we not reorganize simpler functions instead?

d)

... consider the second refactoring to shift responsibility for complex calculations into a VALUE object.

In any case, why does the author suggest that we reorganize functions from entities and place them inside VO? Just because the client makes it more obvious that this operation can be a function?

e)

A side effect can often be completely eliminated by obtaining the VALUE OBJECT value instead of changing the existing state or by moving the entire responsibility in the VALUE OBJECT.

This does not make sense, because, apparently, the author claims that if we move the team (i.e. the operation that changes the state) to VO, then we will essentially eliminate any side effects, even if the team changes the state. So, any ideas what the author was really trying to say?

UPDATE:

1b)

It depends on the perspective. A database query does not change state and, therefore, has no side effects, however, it is not deterministic in nature, since, as you indicate, the data can change. In the book, the author refers to functions associated with the value of the object and entity, which themselves do not perform external calls. Therefore, the rules do not apply to QandC.

Thus, the author described only functions that do not perform external calls, and as such QandC not the type of function that the author described?

1c)

QandC itself does not change state - there are no side effects. ground state can be changed out of band. In this regard, it is not a pure function.

But is this also not a Side-Effect-Free feature in the sense in which the author defined them?

1d)

Again, this is based on CQS.

I know that I am repeating myself, but I believe that the discussion in the book is based on CQS, and CQS does not consider QandC as a side effect function for free due to the probability of returning a QandC object that has its state changed (by some other operation) in the future ?

1e)

The query is considered from the point of view of CQRS, but it cannot be called a function in the sense that a pure function on VO is due to the lack of determinism.

• I don’t quite understand what you were trying to say (the mixing part is in bold). It is possible that while QandC is considered a request, it is not considered a function due to the return of the object and such side effects are unpredictable, which makes QandC non-deterministic in nature

• Thus, the author makes only these statements (see the citation in 1e ) under the implicit assumption that no operation defined in VO will ever try to change the state of objects other than VO?

2d)

Given that VOs are immutable, they are suitable for accommodating pure functions. This is another step towards freeing domain knowledge from technical limitations.

• I don’t understand why moving a function from an object to VO would help free domain knowledge from technical limitations (I’m also not quite sure what you mean by technical - technical, like technological or ...)?

• I assume that another reason for placing a function in VO is because it is much more obvious (to the client) that this is a function?

2e)

I see this as a clue to the source of the events. Instead of changing an existing state, you add a new event that represents the change. There is still a net side effect, however, the existing condition remains stable.

I must admit, I do not know anything about programming using a non-standard source, since I would like to wrap my head around DDD first. In any case, the author did not mean that simply moving the command to VO would automatically eliminate side effects, but instead it would be necessary to take additional actions (for example, implementing event-sourcing), only he “forgot” to mention that part

SECOND UPDATE:

2d)

One of the defining characteristics of an object is its identification .... Having placed business logic in VO, you can consider it outside the context of entity identity. This makes it easy to verify this logic, by the way.

I understand what you are doing (thinking of the concept from a distance), but on the other hand, I really do not. Why function inside an object under the influence of the identity of this object (if this function is a pure function, in other words, it does not change state and is determined)?

2e)

Yes, this is my understanding of this - there is still a pure “side effect”. However, there are different ways to achieve a side effect. One way is to change an existing state. Another way is to make the state change explicitly with the object representing this change.

I - To be sure ... From your answer, which I understood, this author did not mean that side effects would be eliminated simply by moving the command to VO?

II - Well, if I understand you correctly, we can move the command to VO (although VO should not change the state of anything and as such should not cause side effects), and this command is still allowed to create some kind of side effects inside VO but is this side effect somehow more acceptable (OR MORE CONTROLS) by making an explicit state change (which I interpret as the thing that was changed, is returned to the caller as VO)?

3) I have to say that I still do not quite understand why the SC state change method should not return domain objects. Perhaps because non-VO may be changed in some future operations, and therefore the side effects of SC are very unpredictable?

THIRD UPDATE:

The transfer of state control of the essence and the introduction of behavior in HE creates certain advantages. One main division of responsibilities.

a) You say that although a method describes the behavior of an object (and thus the object containing this method adheres to SRP) and, as such, belongs to the entity, it may still be a good idea to move it to VO? Thus, in essence, would we divide the responsibility of the subject into two even smaller responsibilities?

b) But will it not move the behavior in VO, basically turn this object into a simple data container (I understand that the object will still manage its state, but still ...)?

Thank you

Answer 1

1a) Yes. The discourse on the separation of requests from teams is based on the principle of separation of a team request .

1b) It depends on the perspective. A database query does not change state and, therefore, has no side effects, however, it is not deterministic in nature, since, as you indicate, data can change. In the book, the author refers to functions associated with a value object and entities that themselves do not fulfill external challenges. Therefore, the rules do not apply to QandC . However, determinism can be fabricated by offering degrees of "purity." For example, a serializable transaction can be created that can ensure that data does not change over its duration.

1c) QandC itself does not change state - there are no side effects. However, the ground state can be changed out of range. In this regard, this is not a pure function . However, the limitation that QandC does not change state remains valuable. The value is well shown by CQRS , which is a CQS application in distributed scripts.

1d) Again, this is based on CQS. Another thing is the Tell-Don't-Ask principle . However, given the understanding of these principles, the rule may be limited to IMO. The side effect method may return a VO representing the result, for example. However, in some scenarios, such as CQRS + Event Sourcing, it would be desirable for the teams to return void.

1e) It is considered a query from the point of view of CQRS, but it cannot be called a function in the sense that a pure function on VO is a function due to the lack of determinism.

2a) No, the VO function should not change the state of something; instead, it should return a new object.

2b) Yes.

2c) As functional purity tends to become more important in more complex scenarios. However, as you point out, this is not a clear and final rule. It should not be based on complexity, as it is based on a domain.

2d) Given that VOs are immutable, they are suitable for hosting pure functions. This is another step towards freeing domain knowledge from technical limitations.

2e) I see this as a hint to the source of events. Instead of changing an existing state, you add a new event that represents the change. There is still a net side effect, but the existing condition remains stable.

UPDATE

1b) Yes.

1c) This is a free side effect function, but it is not a deterministic function, because you cannot assume that it always returns the same value at the same input. For example, a function that returns the current time is a free side effect function, but it certainly does not return the same value in subsequent calls.

1d) QandC can be seen as a side effect, but not pure. Another way to look at functional purity is referential transparency - the ability to replace a function call by its value without changing the behavior of the program. In other words, asking a question does not change the answer. QandC can guarantee this, but only in a context such as a transaction. Therefore, QandC can be considered as a function, but only in a certain context.

1e) I think the confusing part is that the author specifically talks about functions on VO and entities, and not about database queries, where we talk about both. My expression extends the discussion of database queries and CQRS subject to certain limitations, i.e. External transaction.

2d) I see how what I said was a little vague, I became lazy. One of the defining characteristics of an object is its identification. He retains his identity throughout the life cycle, while his condition may change. By placing business logic in VO, you can consider it outside the context of entity identity. This makes it easy to verify this logic in particular.

2e) Yes, this is my understanding of this - there is still a pure side effect. However, there are different ways to achieve a side effect. One way is to change an existing state. Another way is to make the state change explicit with the object representing this change.

UPDATE 2

2d) This particular point may be argued or may be a matter of preference. One of the prospects is that the idea is based on the principle of single responsibility (PSA). The responsibility of an organization is to combine identity with behavior and condition. Behavior combines input with an existing state to create states. The delegation of government by the entity and the implementation of behavior in HE creates certain advantages. One of them is the main division of responsibilities. The other is more subtle and perhaps more controversial. The idea is that logic can be considered stateless. This makes it easier to think about this logic and think more about a mathematical equation, where all changes are obvious - not a hidden state.

2e.1) Yes, eliminating a net side effect will affect behavior that is not the goal.

2e.2) Yes.

3) Commands returning emptiness have several advantages. Firstly, they become more skilled in asynchronous scenarios - no need to wait for the result. Another is that it allows you to represent the operation as a single object of the command - again, because there is no return value. This applies to CQRS as well as to the event source. In these cases, any output from the command is sent as an event instead of a result. But then again, if these requirements are not applied, a return result may be appropriate.

UPDATE 3

a) Yes, and this is a certain type of partition.

b) The responsibility of the organization is to coordinate behavior by delegating VOs and applying the resulting state changes.