Recompose the client on a layered architecture.

[tetsuharuohzeki]

We're refactoring karen's client side architecture since we forked this. Today's architecture had been aimed to Flux, but this is not completed, and we cannot accept its terminologies directly. So I feel we need to make more concrete vision.

I'll explain some details of my vision in the next comment.

[tetsuharuohzeki]

I'll try to recompose the client with using Model-View-Intent oriented architecture.

• Reactive MVC and the Virtual DOM — Futurice
• Model-View-Intent › Cycle.js

Our application's client side have to handle many input events, so user input, receiving messages, and changing status from servers. We've already introduced Reactive Extensions for JavaScript to process their event streams. But we're using it limitedly because our architecture is still legacy era. We need to recompose them to use Rx more aggressively and to integrate deeply for our event processing architecture.

I tried to refactoring us with using Flux terminology, but I feel it lacks some peaces. It does not have any good terminology for "domain logic". I thought that Store can have a some domain logic, but it's my mis-understanding. I think Store is a view model, not a domain model. If we provide domain logic as Store, this make fat view model which is tightly coupled with domain model.

And Flux's ActionCreator and Dispatcher makes some misleading. By naming & grouping, we feel they are separated materials. But It's mistake. ActionCreator provides an abstraction to call Dispatcher without pass an event type enum. Thus ActionCreator is a function which is named as materialized intent. ActionCreator and Dispatcher should be tightly coupled.

Therefore I'm planning to recompose our code with Model-View-Intent oriented architecture with using some flux's terminology which is for grouping modulations. My current planning is:

• adapter: this might be placed under output.
• intent
  • action
  • dispatcher: this might be melt into action.
• model: as a domain model.
• output
  • store: this might be view model.
  • view: this process a view out put.

These are not fixed. I'm minding some peaces. And this borrows some terminology and thought from The Clean Architecture. And at this moment, I don't think to use cycle.js to resolve this maze.

[tetsuharuohzeki]

Event streams from our server would be an intent. They're tinged with obvious action.

[tetsuharuohzeki]

I'll try to recompose the client with using Model-View-Intent oriented architecture.

I rethought it, the previous one has some missing peaces. So I'll rewrote it.

[tetsuharuohzeki]

Model-View-Intent is just a a pattern, thus I renamed the titile.

[tetsuharuohzeki]

My basic principle to recompose our architecture is here.

And directory tree will be:

• adapter
  • includes driver & adapter roles
• domain
  • includes domain models (entity, value object, and etc)
• intent
  • includes action & dispatcher roles
  • this 'action' naming is derived from Flux, we may rename this role.
  • I feel this role is very similar to Windows Presentation Foundation's command.
  • Should we change this name to command?
• output
  • viewmodel
  • Tthis role has a responsibility of the state of view.
  • view
  • This role has a responsibility of the representation of view.

and we might add some other roles:

• application
  • routing
  • context

[tetsuharuohzeki]

context is a unit of view content area and has a lifecycle itself. context ensure that you have an ownership of the view content area, so you can render something to a given mount point if you are called. This terminology is inspired by Android's Activity. This interface is like:

trait ViewContext {
  fn on_activated(&self, mountpoint: Element);
  fn on_destroy(&self, mountpoint: Element);

  fn on_resume(&self, mountpoint: Element);
  fn on_suspend(&self, mountpoint: Element);
} 

This only provide a lifecyle of view context, does not manage any dependencies. Dependencies are managed by an application layer for each application as most suitable style. So this does not provide any utility system like other react.js meta frameworks because their choice should be freely from our architecture. Each contexts are separated. Theoretically, you can use a raw dom manipulation in context A, use React.js in context B, and use Angular2 in context C.

This does not correspond to body element. context is a unit of view content area which is divided-and-ruled.

[tetsuharuohzeki]

application is a base layer of an application. This layer provides a base routing context, managing dependencies, initializing flow, and etc. This layer should be rewritten to fulfill the requirement for each application.

[tetsuharuohzeki]

viewmodel

This name may confuse me with MVVM pattern's View Model... I thought it provides very similarity role, but I don't have concrete confidence...

[tetsuharuohzeki]

adapter

I write my roughly thought about RPC adapter.

We can express this layer by some functions and some classes, as same as the relationship of between action creator and dispatcher.

The key points is that We can materialize a RPC call concretely with giving a named function returning a Promise/Future/Observable

All RPC call is composited from:

• protocol
• address of endpoint
• type definition of input/output

These 3 key components are very similar to WCF (Windows Communication Foundation) codenamed "Indigo" in Longhorn era.

And RPC client/service should manage connections sessions dispatched by self. Then they can create a returned response value for each requests. This means that: you can get a result as a Promise/Future/Observable even if the request is one way to a service, and you can transform a event stream by flatmapping the result value.