Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Thought about beyond Flux
Layering an application for scalability
Tetsuharu OHZEKI
Github:saneyuki
CAUTION
• This is still a note of my thought.
• Some points are unclear and opaque.
• I believe that we should practice a ...
Keypoints of Flux “pattern”
• Unidirectional data flow + observer pattern + command pattern
• It’s just a Model-View-Inten...
Escape from “Flux” enclosure!
Flux is just a pattern!
Separate a “Responsibility”
• We should separate a “Responsibility” rather than “Concern”.
• The most important point is “...
Separate an internal “layer”
• An internal design is layered naturally if you separate the boundary of a
responsibility.
•...
Example:Windows 7 Architecture
Mark E. Russinovich, David A. Solomon, Alex Ionescu(2012)『インサイドWINDOWS 第6版 上』株式会社クイープ訳, Mic...
Some typical layerings
User input (mouse event)
command (e.g. Flux Action)
domain model
view state model
View presentation
Update UI by some user...
User input (mouse event)
command (e.g. Flux Action)
Update view state model
Update view presentation
Update only UI by som...
User input (mouse event)
command (e.g. Flux Action)
domain model
REST API abstraction
HTTP abstraction (andTCP abstraction...
HTTP abstraction (andTCP abstraction… ?)
REST API abstraction
Update domain model
Update view model
Update view presentati...
Each “layer” is a data transform layer
• A data flow in application is a stacked data transformations which is a result
of...
The benefit of Reactive Extensions
• Unify an asynchronous interface.
• Make each layer boundaries to Observable<T>.
• We ...
Layering example
Driver
Adapter
Domain Domain
Model
Gateway
HTTP Socket
Repository
DB Driver
View
Model
View
Command(Inten...
Is this a Domain Driven Development?
• My interpretation is that domain driven development is one of practical
system.
• I...
This vision is too rich!
• This is a high level abstract concept.
• Rightfully, some hardware/environment/performance limi...
Where is the framework?
• This does not suppose any framework libraries.
• It’s inevitable that All software codebase/repo...
dependency relation (1)
• In Clean Architecture context, domain model layer should not depend on
presentation (driver) lay...
dependency relation (2)
• There need a “connection layer” which connects HAL and specific domain
layer.
• Some runtime sup...
dependency relation (3)
• In a general usecase, its rule should be confirmed that “domain layer don’t
touch a driver layer...
Upcoming SlideShare
Loading in …5
×

My thought about beyond flux

1,285 views

Published on

My personal note about beyond flux pattern to design an application architecture.

Published in: Technology
  • Be the first to comment

My thought about beyond flux

  1. 1. Thought about beyond Flux Layering an application for scalability Tetsuharu OHZEKI Github:saneyuki
  2. 2. CAUTION • This is still a note of my thought. • Some points are unclear and opaque. • I believe that we should practice a way which might not get a glory but never lose for building an application.
  3. 3. Keypoints of Flux “pattern” • Unidirectional data flow + observer pattern + command pattern • It’s just a Model-View-Intent. • http://staltz.com/mvi-freaklies/ • WPF’s “Command” is similar terminology. • One of design patterns than an architecture.
  4. 4. Escape from “Flux” enclosure! Flux is just a pattern!
  5. 5. Separate a “Responsibility” • We should separate a “Responsibility” rather than “Concern”. • The most important point is “cross over the boundary of responsibility”. • In other word, this “responsibility” is a “context”.
  6. 6. Separate an internal “layer” • An internal design is layered naturally if you separate the boundary of a responsibility. • Typical cases: OS’ layering architecture, OSI reference model. • Hardware abstraction, low level API, providing a process lifecycle and a higher level API, running an actual application domain based on APIs, present a computation result, and etc.
  7. 7. Example:Windows 7 Architecture Mark E. Russinovich, David A. Solomon, Alex Ionescu(2012)『インサイドWINDOWS 第6版 上』株式会社クイープ訳, Microsoft Press, p53.
  8. 8. Some typical layerings
  9. 9. User input (mouse event) command (e.g. Flux Action) domain model view state model View presentation Update UI by some user action
  10. 10. User input (mouse event) command (e.g. Flux Action) Update view state model Update view presentation Update only UI by some user action
  11. 11. User input (mouse event) command (e.g. Flux Action) domain model REST API abstraction HTTP abstraction (andTCP abstraction… ?) Dispatch a HTTP request by user action
  12. 12. HTTP abstraction (andTCP abstraction… ?) REST API abstraction Update domain model Update view model Update view presentation Receive a HTTP response & Display it
  13. 13. Each “layer” is a data transform layer • A data flow in application is a stacked data transformations which is a result of each layers. • As a simplified concept, their basis is a result of many map/flatmap computations.
  14. 14. The benefit of Reactive Extensions • Unify an asynchronous interface. • Make each layer boundaries to Observable<T>. • We can compute Observable<T> with using their operators. • Code a data flow graph which are produced from asynchronous events.
  15. 15. Layering example Driver Adapter Domain Domain Model Gateway HTTP Socket Repository DB Driver View Model View Command(Intent)
  16. 16. Is this a Domain Driven Development? • My interpretation is that domain driven development is one of practical system. • I feel there are mixed into some system-specific practices and generic practices. • This session focuses into a generic thought about an architecture • e.g. layering.
  17. 17. This vision is too rich! • This is a high level abstract concept. • Rightfully, some hardware/environment/performance limitations limits a materialization of this concept. • Software engineering is just filling this gap, and the flower of it.
  18. 18. Where is the framework? • This does not suppose any framework libraries. • It’s inevitable that All software codebase/repository make some style/framework in them. • The difference is whether cutting out internal materials from it.
  19. 19. dependency relation (1) • In Clean Architecture context, domain model layer should not depend on presentation (driver) layer. • I agree it as the basic principle. • But it’s hard to apply it strictly…
  20. 20. dependency relation (2) • There need a “connection layer” which connects HAL and specific domain layer. • Some runtime supports like dependency injection would cover and help this connective operation. • So it would be difficult that all relationships among layers are a unidirectional dependency perfectly. • We cannot defined a simple rules :(
  21. 21. dependency relation (3) • In a general usecase, its rule should be confirmed that “domain layer don’t touch a driver layer directly”. • However, of course, we would need to accept some dirty pit holes to resolve performance sensitiveness.

×