Hi Greg,

__._,_.___


__,_._,___

The event fired is directly attached to the behavior that gets triggered by the command handler that passes the needed information from the command to the behavior, so the behavior can determine what and if it should do something. So in that way the command couldn't tell anything more than the published event can. Events are not only for state changes they can contain other important information as well, the one thing that is important is that state change can only happen through events. Capturing the commands by it self is not enough, you need to also capture the results of the business logic in order to get your audit log (i.e. state changes) because state may or may not change depending on the information provided. So by logging the events you are sure that you have captured: why it happened (event type), it will tell you what state got changed and it can tell you what information was provided to the behavior.

Now if someone can temper with your audit logs whether they are the stored events Greg talks about or they are in your suggested form then you are lost and they lost their value. Hence the suggestion to store these events on a write only medium.

With respect to proving your audit logs (taking out of the equation tempering of these logs outside the system) if an audit log is about the why, what and how an AR changed state and this is the same information that is used to build up the AR each time you need it, then the audit log and AR cannot be out of sync, right? But if you have two different things, one part makes the audit log and an other part is updating the AR, then these two may not be equal. I would say that it is more likely that a bug is introduced in the later approach then in the first approach. If you have to make a change in your domain logic resulting in different behvior then when using the events then there is one place that needs to be looked after, but when separating these two you have two places that needs to be updated.

One other thing that has not been mentioned (I believe) is that when you write your tests to verify that your behavior is triggering the correct results when using the events solution you will test both the domain behavior result and the auditing of these results, but when separating these two you also need to test for these two independently. Because if auditing is of such high importance as you say then I would assume you also test that you actually audit to correct information, even if it is done automatically?

-Mark

 

Hi Greg,

Thank you for your detailed reply.  I'll start with the end by getting rid of minor concerns.

It is correct in that it shows how the system believes we got to where we are and that it will always match up to where we actually are (regardless of bugs etc). It's not saying that the software is correct, it is the audit trail that is correct.

You only know where you actually are because the log told you in the first place. So you simply accept anything the logs tell you and use that information to prove that the log itself is correct. All Audit Logs would be correct in those terms so why do ask for the proof? Geez, can't you guys see the recursion here? 

: this : log : has  : five : words

later someone tempered with the logs, some bug or whatever. The truth gets rewritten.

: this : log : has : ten : words 

: this : log : has : ten : or more : words

: words

 

You always end up with "words" i n the current state yet the system beliefs about how you got there were changed to use your words. By your definition the log is still correct. 

Greg honestly, this for me is really a detail so let's just say your interpretation of correctness is useless for my clients. We they would need more checks if correctness was a concern. Others might think differently and feel safe with it just as it is, ok.

You wouldn't do such a report off your event log! It would be done off the read model. The only thing the event store is ever used for is to load up an aggregate to process a behavior.

So it seams your Audit Log does fall right on the sweet spot of the following Martin's observation:

So it all depends how tightly the accessing of temporal information is integrated into your regular software process. The tighter the integration, the less useful is Audit Log.

I think Martin is saying useful as a replacement for other temporal patterns in general, that includes to model time driven business transactions, the theme of a lot of domain models. In this regard IMHO you have a weak case compared with other approaches considering. Yet there are indeed other non functional properties that I find interesting in your approach. When I first heard about it I thought it would be the cure for most of my temporal challenges .... my fault.

 have said this before but the problem with automatic tracking is that you lose the business value. Do you care whether the trader manually edited his order to 100 shares or that it is now 100 shares? It de pends on the question. An automatic system would only let you ask what the value was. We admittedly have no way of guessing the kinds of questions we will want to ask in 10 years

Is not that you loose the business value yet it is reduced, but are correct it can be improved.

I already suggested building an automatic state change auditing tool that could take the command that provoked the state change to construct metadata around the record. This IMO would already provide a lot of context for later use. I think it is even possible for the such a system to generate a structures similar to the ones you probably use and translate the command to the past tense and voila. 

After all, paying attention to what changes in consequence of applying a command, make a struct with those properties, new the struct, pass the values to the struct .... that is what the extremely productive programers would be doing a lot of the times, one of the admitted drawbacks of your formula. So why not remove this burden?  Do these tasks actually improve the programmer sense for object behavior in general? Do this tasks actually improve the quality of the domain model by simple reformulating the name of the command or method and label a struct, something probably not  even required in the first place? The time spent doing this could be used to improve the design of the domain model, make better tests etc I think. Saying that "we made the state change a domain concept " is not good enough, it needs to be necessary.

If the automatic system takes in the command info that lead to the state change and use it to create metadata as I suggested above, in my view would provide the needed context for most cases.

We would still be able to reconstruct your ARs the way you do as it seams to be one of the facets you and others seam very keen. And we would have an audit log with information of all things encompassing state change augmented with command metadata to enhance its business value by exposing use case context otherwise lost.

The second problem with an automatic mechanism is that you tend to denoemalize the results of calculations to enrich events (they aren't only the state change but often include information about the context such as the result of some call locally)

If the result of that calculation is important for the record then put it in an object attribute or field. As you have said it is impossible to conceive what would be the data needs of the future so wouldn't this qualify as a good attempt?. The domain model will for sure change to cope with those needs and so will eithe r your custom made audit log or one audit log created automatically.

I'll not debate the rest as I think this medium wouldn't allow exchanging ideas in an efficient way . For the record I was not using the term transaction as a function or use case but as per SOM (a significant temporal business event where multiple parties get together in a place to perform an action) , so not at all standard view. In this light I agree that all domain driven actions can be translated to functions, commands or methods of an object nevertheless only some I would characterize as transactions.

Cheers,

Nuno

PS: Yes the iphone is ... well I love it and I hate it. Happened to me when my child was born.

__._,_.___


__,_._,___

 

Hi Greg,

Thank you for your detailed reply.  I'll start with the end by getting rid of minor concerns.

It is correct in that it shows how the system believes we got to where we are and that it will always match up to where we actually are (regardless of bugs etc). It's not saying that the software is correct, it is the audit trail that is correct.

You only know where you actually are because the log told you in the first place. So you simply accept anything the logs tell you and use that information to prove that the log itself is correct. All Audit Logs would be correct in those terms so why do ask for the proof? Geez, can't you guys see the recursion here? 

: this : log : has  : five : words

later someone tempered with the logs, some bug or whatever. The truth gets rewritten.

: this : log : has : ten : words 

: this : log : has : ten : or more : words

: words

 

You always end up with "words" i n the current state yet the system beliefs about how you got there were changed to use your words. By your definition the log is still correct. 

Greg honestly, this for me is really a detail so let's just say your interpretation of correctness is useless for my clients. We they would need more checks if correctness was a concern. Others might think differently and feel safe with it just as it is, ok.

You wouldn't do such a report off your event log! It would be done off the read model. The only thing the event store is ever used for is to load up an aggregate to process a behavior.

So it seams your Audit Log does fall right on the sweet spot of the following Martin's observation:

So it all depends how tightly the accessing of temporal information is integrated into your regular software process. The tighter the integration, the less useful is Audit Log.

I think Martin is saying useful as a replacement for other temporal patterns in general, that includes to model time driven business transactions, the theme of a lot of domain models. In this regard IMHO you have a weak case compared with other approaches considering. Yet there are indeed other non functional properties that I find interesting in your approach. When I first heard about it I thought it would be the cure for most of my temporal challenges .... my fault.

 have said this before but the problem with automatic tracking is that you lose the business value. Do you care whether the trader manually edited his order to 100 shares or that it is now 100 shares? It de pends on the question. An automatic system would only let you ask what the value was. We admittedly have no way of guessing the kinds of questions we will want to ask in 10 years

Is not that you loose the business value yet it is reduced, but are correct it can be improved.

I already suggested building an automatic state change auditing tool that could take the command that provoked the state change to construct metadata around the record. This IMO would already provide a lot of context for later use. I think it is even possible for the such a system to generate a structures similar to the ones you probably use and translate the command to the past tense and voila. 

After all, paying attention to what changes in consequence of applying a command, make a struct with those properties, new the struct, pass the values to the struct .... that is what the extremely productive programers would be doing a lot of the times, one of the admitted drawbacks of your formula. So why not remove this burden?  Do these tasks actually improve the programmer sense for object behavior in general? Do this tasks actually improve the quality of the domain model by simple reformulating the name of the command or method and label a struct, something probably not  even required in the first place? The time spent doing this could be used to improve the design of the domain model, make better tests etc I think. Saying that "we made the state change a domain concept " is not good enough, it needs to be necessary.

If the automatic system takes in the command info that lead to the state change and use it to create metadata as I suggested above, in my view would provide the needed context for most cases.

We would still be able to reconstruct your ARs the way you do as it seams to be one of the facets you and others seam very keen. And we would have an audit log with information of all things encompassing state change augmented with command metadata to enhance its business value by exposing use case context otherwise lost.

The second problem with an automatic mechanism is that you tend to denoemalize the results of calculations to enrich events (they aren't only the state change but often include information about the context such as the result of some call locally)

If the result of that calculation is important for the record then put it in an object attribute or field. As you have said it is impossible to conceive what would be the data needs of the future so wouldn't this qualify as a good attempt?. The domain model will for sure change to cope with those needs and so will eithe r your custom made audit log or one audit log created automatically.

I'll not debate the rest as I think this medium wouldn't allow exchanging ideas in an efficient way . For the record I was not using the term transaction as a function or use case but as per SOM (a significant temporal business event where multiple parties get together in a place to perform an action) , so not at all standard view. In this light I agree that all domain driven actions can be translated to functions, commands or methods of an object nevertheless only some I would characterize as transactions.

Cheers,

Nuno

PS: Yes the iphone is ... well I love it and I hate it. Happened to me when my child was born.

__._,_.___


__,_._,___

 

The event fired is directly attached to the behavior that gets triggered by the command handler that passes the needed information from the command to the behavior, so the behavior can determine what and if it should do something. So in that way the command couldn't tell anything more than the published event can. Events are not only for state changes they can contain other important information as well, the one thing that is important is that state change can only happen through events. Capturing the commands by it self is not enough, you need to also capture the results of the business logic in order to get your audit log (i.e. state changes) because state may or may not change depending on the information provided. So by logging the events you are sure that you have captured: why it happened (event type), it will tell you what state got changed and it can tell you what information was provided to the behavior.

Now if someone can temper with your audit logs whether they are the stored events Greg talks about or they are in your suggested form then you are lost and they lost their value. Hence the suggestion to store these events on a write only medium.

With respect to proving your audit logs (taking out of the equation tempering of these logs outside the system) if an audit log is about the why, what and how an AR changed state and this is the same information that is used to build up the AR each time you need it, then the audit log and AR cannot be out of sync, right? But if you have two different things, one part makes the audit log and an other part is updating the AR, then these two may not be equal. I would say that it is more likely that a bug is introduced in the later approach then in the first approach. If you have to make a change in your domain logic resulting in different behvior then when using the events then there is one place that needs to be looked after, but when separating these two you have two places that needs t o be updated.

One other thing that has not been mentioned (I believe) is that when you write your tests to verify that your behavior is triggering the correct results when using the events solution you will test both the domain behavior result and the auditing of these results, but when separating these two you also need to test for these two independently. Because if auditing is of such high importance as you say then I would assume you also test that you actually audit to correct information, even if it is done automatically?

-Mark

On Sun, Nov 1, 2009 at 1:35 AM, Nuno Lopes <nbplopes <at> gmail.com> wrote:

 

Hi Greg,

Thank you for your detailed reply.  I'll start with the end by getting rid of minor concerns.

It is correct in that it shows how the system believes we got to where we are and that it will always match up to where we actually are (regardless of bugs etc). It's not saying that the software is correct, it is the audit trail that is correct.

You only know where you actually are because the log told you in the first place. So you simply accept anything the logs tell you and use that information to prove that the log itself is correct. All Audit Logs would be correct in those terms so why do ask for the proof? Geez, can't you guys see the recursion here? 

: this : log : has  : five : words

later someone tempered with the logs, some bug or whatever. The truth gets rewritten.

: this : log : has : ten : words 

: this : log : has : ten : or more : words

: words

 

You always end up with "words" in the current state yet the system beliefs about how you got there were changed to use your words. By your definition the log is still correct. 

Greg honestly, this for me is really a detail so let's just say your interpretation of correctness is useless for my clients. We they would need more checks if correctness was a concern. Others might think differently and feel safe with it just as it is, ok.

You wouldn't do such a report off your event log! It would be done off the read model. The only thing the event store is ever used for is to load up an aggregate to process a behavior.

So it seams your Audit Log does fall right on the sweet spot of the following Martin's observation:

So it all depends how tightly the accessing of temporal information is integrated into your regular software process. The tighter the integration, the less useful is Audit Log.

I think Martin is saying useful as a replacement for other temporal patterns in general, that includes to model time driven business transactions, the theme of a lot of domain models. In this regard IMHO you have a weak case compared with other approaches considering. Yet there are indeed other non functional properties that I find interesting in your approach. When I first heard about it I thought it would be the cure for most of my temporal challenges .... my fault.

 have said this before but the problem with automatic tracking is that you lose the business value. Do you care whether the trader manually edited his order to 100 shares or that it is now 100 shares? It depends on the question. An automatic system would only let you ask what the value was. We admittedly have no way of guessing the kinds of questions we will want to ask in 10 years

Is not that you loose the business value yet it is reduced, but are correct it can be improved.

I already suggested building an automatic state change auditing tool that could take the command that provoked the state change to construct metadata around the record. This IMO would already provide a lot of context for later use. I think it is even possible for the such a system to generate a structures similar to the ones you probably use and translate the command to the past tense and voila. 

After all, paying attention to what changes in consequence of applying a command, make a struct with those properties, new the struct, pass the values to the struct .... that is what the extremely productive programers would be doing a lot of the times, one of the admitted drawbacks of your formula. So why not remove this burden?  Do these tasks actually improve the programmer sense for object behavior in general? Do this tasks actually improve the quality of the domain model by simple reformulating the name of the command or method and label a struct, something probably not  even required in the first place? The time spent doing this could be used to improve the design of the domain model, make better tests etc I think. Saying that "we made the state change a domain concept" is not good enough, it needs to be necessary.

If the automatic system takes in the command info that lead to the state change and use it to create metadata as I suggested above, in my view would provide the needed context for most cases.

We would still be able to reconstruct your ARs the way you do as it seams to be one of the facets you and others seam very keen. And we would have an audit log with information of all things encompassing state change augmented with command metadata to enhance its business value by exposing use case context otherwise lost.

The second problem with an automatic mechanism is that you tend to denoemalize the results of calculations to enrich events (they aren't only the state change but often include information about the context such as the result of some call locally)

If the result of that calculation is important for the record then put it in an object attribute or field. As you have said it is impossible to conceive what would be the data needs of the future so wouldn't this qualify as a good attempt?. The domain model will for sure change to cope with those needs and so will either your custom made audit log or one audit log created automatically.

I'll not debate the rest as I think this medium wouldn't allow exchanging ideas in an efficient way . For the record I was not using the term transaction as a function or use case but as per SOM (a significant temporal business event where multiple parties get together in a place to perform an action) , so not at all standard view. In this light I agree that all domain driven actions can be translated to functions, commands or methods of an object nevertheless only some I would characterize as transactions.

Cheers,

Nuno

PS: Yes the iphone is ... well I love it and I hate it. Happened to me when my child was born.

__._,_.___


__,_._,___

>Write only would be pretty useless

If only they don't generate events as a result of their state change ;)

 

I think you mean write once media mark? Write only would be pretty useless

Greg

Sent from my iPhone

On 2009-11-01, at 3:23, Mark Nijhof <Mark.Nijhof <at> Gmail.com> wrote:

 

The event fired is directly attached to the behavior that gets triggered by the command handler that passes the needed information from the command to the behavior, so the behavior can determine what and if it should do something. So in that way the command couldn't tell anything more than the published event can. Events are not only for state changes they can contain other important information as well, the one thing that is important is that state change can only happen through events. Capturing the commands by it self is not enough, you need to also capture the results of the business logic in order to get your audit log (i.e. state changes) because state may or may not change depending on the information provided. So by logging the events you are sure that you have captured: why it happened (event type), it will tell you what state got changed and it can tell you what information was provided to the behavior.

Now if someone can temper with your audit logs whether they are the stored events Greg talks about or they are in your suggested form then you are lost and they lost their value. Hence the suggestion to store these events on a write only medium.

With respect to proving your audit logs (taking out of the equation tempering of these logs outside the system) if an audit log is about the why, what and how an AR changed state and this is the same information that is used to build up the AR each time you need it, then the audit log and AR cannot be out of sync, right? But if you have two different things, one part makes the audit log and an other part is updating the AR, then these two may not be equal. I would say that it is more likely that a bug is introduced in the later approach then in the first approach. If you have to make a change in your domain logic resulting in different behvior then when using the events then there is one place that needs to be looked after, but when separating these two you have two places that needs t o be updated.

One other thing that has not been mentioned (I believe) is that when you write your tests to verify that your behavior is triggering the correct results when using the events solution you will test both the domain behavior result and the auditing of these results, but when separating these two you also need to test for these two independently. Because if auditing is of such high importance as you say then I would assume you also test that you actually audit to correct information, even if it is done automatically?

-Mark

On Sun, Nov 1, 2009 at 1:35 AM, Nuno Lopes <nbplopes <at> gmail.com> wrote:

 

Hi Greg,

Thank you for your detailed reply.  I'll start with the end by getting rid of minor concerns.

It is correct in that it shows how the system believes we got to where we are and that it will always match up to where we actually are (regardless of bugs etc). It's not saying that the software is correct, it is the audit trail that is correct.

You only know where you actually are because the log told you in the first place. So you simply accept anything the logs tell you and use that information to prove that the log itself is correct. All Audit Logs would be correct in those terms so why do ask for the proof? Geez, can't you guys see the recursion here? 

: this : log : has  : five : words

later someone tempered with the logs, some bug or whatever. The truth gets rewritten.

: this : log : has : ten : words 

: this : log : has : ten : or more : words

: words

 

You always end up with "words" in the current state yet the system beliefs about how you got there were changed to use your words. By your definition the log is still correct. 

Greg honestly, this for me is really a detail so let's just say your interpretation of correctness is useless for my clients. We they would need more checks if correctness was a concern. Others might think differently and feel safe with it just as it is, ok.

You wouldn't do such a report off your event log! It would be done off the read model. The only thing the event store is ever used for is to load up an aggregate to process a behavior.

So it seams your Audit Log does fall right on the sweet spot of the following Martin's observation:

So it all depends how tightly the accessing of temporal information is integrated into your regular software process. The tighter the integration, the less useful is Audit Log.

I think Martin is saying useful as a replacement for other temporal patterns in general, that includes to model time driven business transactions, the theme of a lot of domain models. In this regard IMHO you have a weak case compared with other approaches considering. Yet there are indeed other non functional properties that I find interesting in your approach. When I first heard about it I thought it would be the cure for most of my temporal challenges .... my fault.

 have said this before but the problem with automatic tracking is that you lose the business value. Do you care whether the trader manually edited his order to 100 shares or that it is now 100 shares? It depends on the question. An automatic system would only let you ask what the value was. We admittedly have no way of guessing the kinds of questions we will want to ask in 10 years

Is not that you loose the business value yet it is reduced, but are correct it can be improved.

I already suggested building an automatic state change auditing tool that could take the command that provoked the state change to construct metadata around the record. This IMO would already provide a lot of context for later use. I think it is even possible for the such a system to generate a structures similar to the ones you probably use and translate the command to the past tense and voila. 

After all, paying attention to what changes in consequence of applying a command, make a struct with those properties, new the struct, pass the values to the struct .... that is what the extremely productive programers would be doing a lot of the times, one of the admitted drawbacks of your formula. So why not remove this burden?  Do these tasks actually improve the programmer sense for object behavior in general? Do this tasks actually improve the quality of the domain model by simple reformulating the name of the command or method and label a struct, something probably not  even required in the first place? The time spent doing this could be used to improve the design of the domain model, make better tests etc I think. Saying that "we made the state change a domain concept" is not good enough, it needs to be necessary.

If the automatic system takes in the command info that lead to the state change and use it to create metadata as I suggested above, in my view would provide the needed context for most cases.

We would still be able to reconstruct your ARs the way you do as it seams to be one of the facets you and others seam very keen. And we would have an audit log with information of all things encompassing state change augmented with command metadata to enhance its business value by exposing use case context otherwise lost.

The second problem with an automatic mechanism is that you tend to denoemalize the results of calculations to enrich events (they aren't only the state change but often include information about the context such as the result of some call locally)

If the result of that calculation is important for the record then put it in an object attribute or field. As you have said it is impossible to conceive what would be the data needs of the future so wouldn't this qualify as a good attempt?. The domain model will for sure change to cope with those needs and so will either your custom made audit log or one audit log created automatically.

I'll not debate the rest as I think this medium wouldn't allow exchanging ideas in an efficient way . For the record I was not using the term transaction as a function or use case but as per SOM (a significant temporal business event where multiple parties get together in a place to perform an action) , so not at all standard view. In this light I agree that all domain driven actions can be translated to functions, commands or methods of an object nevertheless only some I would characterize as transactions.

Cheers,

Nuno

PS: Yes the iphone is ... well I love it and I hate it. Happened to me when my child was born.

__._,_.___


__,_._,___