3 added 219 characters in body
source | link

I find this problem too confusing and it would take lots of text and time to properly explain the problem as I believe you misunderstand both Martin's Clean Architecture and MVVM.

First thing to note, is that the diagram you posted is incomplete. It only shows "business logic", but is missing some kind of "orchestrator" that actually makes the parts move in the right order. enter image description here

The code of orchestrator would be as simple as

string Request(string request) // returns response
{
    Controller.Run(data);
    Presenter.Run();
    return View.Run();
}

I believe I heard Martin talk about this in one of his talks about Clean Architecture.

Another thing to point out is that candied_orange's remark about lack of cycles is wrong. Yes, the cycled don't exist (and shouldn't) in the architecture of the code. But cycles between runtime instances are common and often lead to simpler design.

That is case in MVVM. In MVVM View depends on ViewModel, and ViewModel uses events to notify View about it's changes. This means that in the design of the classes, there is only dependency from View to Model classes, but during runtime, there is cyclical dependency between View and ViewModel instances. Because of this, there is no need for orchestrator, as ViewModel will provide View way to figure out when to update itself. This is why "notifications" in this diagram use "squigly" line and not direct line. It means View observes changes in ViewModel, not that ViewModel depends on View.

enter image description here

The most important thing you should take from Martin's Clean Architecture is not the design itself, but how you handle dependencies. One of the critical points he makes in his talks is that when there is a boundary, then all code dependencies crossing that boundary cross it in single direction. In the diagram, this boundary is represented by double line. And there is lots of dependency inversion through interfaces (InputBoundary, OutputBoundary and DataAccessInterface) that fixes the code dependency direction.

In contrast the ViewModel in Clean Architecture is just plain DTO with no logic. This is made obvious by <DS> tag. And this is reason why orchestrator is necessary, as View won't know when to run it's logic.

If I were to "flatten" the diagram into what will it look like during runtime, it will look like this:

enter image description here

So during runtime, the dependencies are in "wrong" direction, but that is fine.

I recommend watching his talk about Clean Architecture to better understand his reasoning.

I find this problem too confusing and it would take lots of text and time to properly explain the problem as I believe you misunderstand both Martin's Clean Architecture and MVVM.

First thing to note, is that the diagram you posted is incomplete. It only shows "business logic", but is missing some kind of "orchestrator" that actually makes the parts move in the right order. enter image description here

The code of orchestrator would be as simple as

string Request(string request) // returns response
{
    Controller.Run(data);
    Presenter.Run();
    return View.Run();
}

I believe I heard Martin talk about this in one of his talks about Clean Architecture.

Another thing to point out is that candied_orange's remark about lack of cycles is wrong. Yes, the cycled don't exist (and shouldn't) in the architecture of the code. But cycles between runtime instances are common and often lead to simpler design.

That is case in MVVM. In MVVM View depends on ViewModel, and ViewModel uses events to notify View about it's changes. This means that in the design of the classes, there is only dependency from View to Model classes, but during runtime, there is cyclical dependency between View and ViewModel instances. Because of this, there is no need for orchestrator, as ViewModel will provide View way to figure out when to update itself. This is why "notifications" in this diagram use "squigly" line and not direct line. It means View observes changes in ViewModel, not that ViewModel depends on View.

enter image description here

The most important thing you should take from Martin's Clean Architecture is not the design itself, but how you handle dependencies. One of the critical points he makes in his talks is that when there is a boundary, then all code dependencies crossing that boundary cross it in single direction. In the diagram, this boundary is represented by double line. And there is lots of dependency inversion through interfaces (InputBoundary, OutputBoundary and DataAccessInterface) that fixes the code dependency direction.

If I were to "flatten" the diagram into what will it look like during runtime, it will look like this:

enter image description here

So during runtime, the dependencies are in "wrong" direction, but that is fine.

I recommend watching his talk about Clean Architecture to better understand his reasoning.

I find this problem too confusing and it would take lots of text and time to properly explain the problem as I believe you misunderstand both Martin's Clean Architecture and MVVM.

First thing to note, is that the diagram you posted is incomplete. It only shows "business logic", but is missing some kind of "orchestrator" that actually makes the parts move in the right order. enter image description here

The code of orchestrator would be as simple as

string Request(string request) // returns response
{
    Controller.Run(data);
    Presenter.Run();
    return View.Run();
}

I believe I heard Martin talk about this in one of his talks about Clean Architecture.

Another thing to point out is that candied_orange's remark about lack of cycles is wrong. Yes, the cycled don't exist (and shouldn't) in the architecture of the code. But cycles between runtime instances are common and often lead to simpler design.

That is case in MVVM. In MVVM View depends on ViewModel, and ViewModel uses events to notify View about it's changes. This means that in the design of the classes, there is only dependency from View to Model classes, but during runtime, there is cyclical dependency between View and ViewModel instances. Because of this, there is no need for orchestrator, as ViewModel will provide View way to figure out when to update itself. This is why "notifications" in this diagram use "squigly" line and not direct line. It means View observes changes in ViewModel, not that ViewModel depends on View.

enter image description here

The most important thing you should take from Martin's Clean Architecture is not the design itself, but how you handle dependencies. One of the critical points he makes in his talks is that when there is a boundary, then all code dependencies crossing that boundary cross it in single direction. In the diagram, this boundary is represented by double line. And there is lots of dependency inversion through interfaces (InputBoundary, OutputBoundary and DataAccessInterface) that fixes the code dependency direction.

In contrast the ViewModel in Clean Architecture is just plain DTO with no logic. This is made obvious by <DS> tag. And this is reason why orchestrator is necessary, as View won't know when to run it's logic.

If I were to "flatten" the diagram into what will it look like during runtime, it will look like this:

enter image description here

So during runtime, the dependencies are in "wrong" direction, but that is fine.

I recommend watching his talk about Clean Architecture to better understand his reasoning.

2 added 106 characters in body
source | link

I find this problem too confusing and it would take lots of text and time to properly explain the problem as I believe you misunderstand both Martin's Clean Architecture and MVVM.

First thing to note, is that the diagram you posted is incomplete. It only shows "business logic", but is missing some kind of "orchestrator" that actually makes the parts move in the right order. enter image description here

The code of orchestrator would be as simple as

string Request(string request) // returns response
{
    Controller.Run(data);
    Presenter.Run();
    return View.Run();
}

I believe I heard Martin talk about this in one of his talks about Clean Architecture.

Another thing to point out is that candied_orange's remark about lack of cycles is wrong. Yes, the cycled don't exist (and shouldn't) in the architecture of the code. But cycles between runtime instances are common and often lead to simpler design.

That is case in MVVM. In MVVM View depends on ViewModel, and ViewModel uses events to notify View about it's changes. This means that in the design of the classes, there is only dependency from View to Model classes, but during runtime, there is cyclical dependency between View and ViewModel instances. Because of this, there is no need for orchestrator, as ViewModel will provide View way to figure out when to update itself. This is why "notifications" in this diagram use "squigly" line and not direct line. It means View observes changes in ViewModel, not that ViewModel depends on View.

enter image description here

The most important thing you should take from Martin's Clean Architecture is not the design itself, but how you handle dependencies. One of the critical points he makes in his talks is that when there is a boundary, then all code dependencies crossing that boundary cross it in single direction. In the diagram, this boundary is represented by double line. And there is lots of dependency inversion through interfaces (InputBoundary and, OutputBoundary and DataAccessInterface) that fixes the code dependency direction.

If I were to "flatten" the diagram into what will it look like during runtime, it will look like this:

enter image description here

So during runtime, the dependencies are in "wrong" direction, but that is fine.

I recommend watching his talk about Clean Architecture to better understand his reasoning.

I find this problem too confusing and it would take lots of text and time to properly explain the problem as I believe you misunderstand both Martin's Clean Architecture and MVVM.

First thing to note, is that the diagram you posted is incomplete. It only shows "business logic", but is missing some kind of "orchestrator" that actually makes the parts move in the right order. enter image description here

The code of orchestrator would be as simple as

string Request(string request) // returns response
{
    Controller.Run(data);
    Presenter.Run();
    return View.Run();
}

I believe I heard Martin talk about this in one of his talks about Clean Architecture.

Another thing to point out is that candied_orange's remark about lack of cycles is wrong. Yes, the cycled don't exist (and shouldn't) in the architecture of the code. But cycles between runtime instances are common and often lead to simpler design.

That is case in MVVM. In MVVM View depends on ViewModel, and ViewModel uses events to notify View about it's changes. This means that in the design of the classes, there is only dependency from View to Model classes, but during runtime, there is cyclical dependency between View and ViewModel instances. Because of this, there is no need for orchestrator, as ViewModel will provide View way to figure out when to update itself. This is why "notifications" in this diagram use "squigly" line and not direct line. It means View observes changes in ViewModel, not that ViewModel depends on View.

enter image description here

The most important thing you should take from Martin's Clean Architecture is not the design itself, but how you handle dependencies. One of the critical points he makes in his talks is that when there is a boundary, then all code dependencies crossing that boundary cross it in single direction. In the diagram, this boundary is represented by double line. And there is lots of dependency inversion through interfaces (InputBoundary and OutputBoundary) that fixes the code dependency direction.

If I were to "flatten" the diagram into what will it look like during runtime, it will look like this:

enter image description here

I recommend watching his talk about Clean Architecture to better understand his reasoning.

I find this problem too confusing and it would take lots of text and time to properly explain the problem as I believe you misunderstand both Martin's Clean Architecture and MVVM.

First thing to note, is that the diagram you posted is incomplete. It only shows "business logic", but is missing some kind of "orchestrator" that actually makes the parts move in the right order. enter image description here

The code of orchestrator would be as simple as

string Request(string request) // returns response
{
    Controller.Run(data);
    Presenter.Run();
    return View.Run();
}

I believe I heard Martin talk about this in one of his talks about Clean Architecture.

Another thing to point out is that candied_orange's remark about lack of cycles is wrong. Yes, the cycled don't exist (and shouldn't) in the architecture of the code. But cycles between runtime instances are common and often lead to simpler design.

That is case in MVVM. In MVVM View depends on ViewModel, and ViewModel uses events to notify View about it's changes. This means that in the design of the classes, there is only dependency from View to Model classes, but during runtime, there is cyclical dependency between View and ViewModel instances. Because of this, there is no need for orchestrator, as ViewModel will provide View way to figure out when to update itself. This is why "notifications" in this diagram use "squigly" line and not direct line. It means View observes changes in ViewModel, not that ViewModel depends on View.

enter image description here

The most important thing you should take from Martin's Clean Architecture is not the design itself, but how you handle dependencies. One of the critical points he makes in his talks is that when there is a boundary, then all code dependencies crossing that boundary cross it in single direction. In the diagram, this boundary is represented by double line. And there is lots of dependency inversion through interfaces (InputBoundary, OutputBoundary and DataAccessInterface) that fixes the code dependency direction.

If I were to "flatten" the diagram into what will it look like during runtime, it will look like this:

enter image description here

So during runtime, the dependencies are in "wrong" direction, but that is fine.

I recommend watching his talk about Clean Architecture to better understand his reasoning.

1
source | link

I find this problem too confusing and it would take lots of text and time to properly explain the problem as I believe you misunderstand both Martin's Clean Architecture and MVVM.

First thing to note, is that the diagram you posted is incomplete. It only shows "business logic", but is missing some kind of "orchestrator" that actually makes the parts move in the right order. enter image description here

The code of orchestrator would be as simple as

string Request(string request) // returns response
{
    Controller.Run(data);
    Presenter.Run();
    return View.Run();
}

I believe I heard Martin talk about this in one of his talks about Clean Architecture.

Another thing to point out is that candied_orange's remark about lack of cycles is wrong. Yes, the cycled don't exist (and shouldn't) in the architecture of the code. But cycles between runtime instances are common and often lead to simpler design.

That is case in MVVM. In MVVM View depends on ViewModel, and ViewModel uses events to notify View about it's changes. This means that in the design of the classes, there is only dependency from View to Model classes, but during runtime, there is cyclical dependency between View and ViewModel instances. Because of this, there is no need for orchestrator, as ViewModel will provide View way to figure out when to update itself. This is why "notifications" in this diagram use "squigly" line and not direct line. It means View observes changes in ViewModel, not that ViewModel depends on View.

enter image description here

The most important thing you should take from Martin's Clean Architecture is not the design itself, but how you handle dependencies. One of the critical points he makes in his talks is that when there is a boundary, then all code dependencies crossing that boundary cross it in single direction. In the diagram, this boundary is represented by double line. And there is lots of dependency inversion through interfaces (InputBoundary and OutputBoundary) that fixes the code dependency direction.

If I were to "flatten" the diagram into what will it look like during runtime, it will look like this:

enter image description here

I recommend watching his talk about Clean Architecture to better understand his reasoning.