Enhancing clean architecture: 2 n-dimensional layers

2. Acknowledgments I’d like to thank my colleague Gheorghe Ratcu: its work related to similar aspects validate my pursue for a common approach for different kind of “interactions”. (c) Copyright 2017 Valentin Tudor Mocanu 2

3. Valentin Tudor Mocanu • Various development roles • Agile Training (Scrum, XP, Disciplined Agile) • Certified Disciplined Agile Coach/Instructor • Disciplined Agile Consortium Bronze Partner • Process Coach/Project Manager at PSS Prosoft-Solution • Domains: document management, simulators and retail • Interests: disciplined agile, eliminate waste, adapt the process, cross-functional skills, non-solo development, clean code, clean architecture, adaptive design and adaptive products. (c) Copyright 2017 Valentin Tudor Mocanu 3

4. Once upon a time … I believe that the first skill needed by a developer is to know how to build a system Further experiences make me reconsider and rethink this aspect. (c) Copyright 2017 Valentin Tudor Mocanu 4

6. The first responsibility of a programmer is to be able to change the system • … indefinitely • … with inexpensive adaptability • … quick • …. with extreme quality • …. with stable productivity. … wait, that is just another definition of Agility? • Note: inspired by Robert C. Martin (See B6) (c) Copyright 2017 Valentin Tudor Mocanu 6

8. What is the ugly truth? • We may have formally layers, components, MVC, but … • 75% of our code is in UI classes • … and most of the rest in DAOs • Same design element has too many responsibilities: UI, business, file management and more • Code is fragile and rigid: hard to change, break easily on changes. That is a bad economics! • As Robert C. Martin said, when our product is fragile, the customers and the management believe that developers have no idea and no control about wat they are doing (c) Copyright 2017 Valentin Tudor Mocanu 8

11. Misconception: Business is on “Server” Misconception related to Layered Architecture • Presentation is UI and this is the “Client” • Business and Persistence are on the ”Server” What is this mythical “Server”? • It is a bird, it is a plane? • It is a machine, an application server, a db server? What is really happening? • Presentation need also some business and flow • Design separation vs. Deployment types • We can also deploy a good part of Presentation on physical server • We can have most of the business used by Interaction part (c) Copyright 2017 Valentin Tudor Mocanu 11

12. Some real challenges • Product A • Same command could come from UI, but also from the network (game-like) • Product B • Different kind of persistence: classical DB, specific API DB in files, text files • Product C • Import/export formatted info from/to files combined with persistency • Emails • SMSs • Changes • Functionality changes: business rules or flows • Technology changes (c) Copyright 2017 Valentin Tudor Mocanu 12

13. Real “Layered Architecture” • Classical problem – still mix the responsibilities • Views (UI) send emails or send SMSs • Views and DAOs import and from files and process content • Privileged “seats” for Presentation and Persistency (consequences): • Any I/O aspect will be introduced into UI/Persistency design elements • … some business rules will follow • … Presentation/Persistency will have undesired flow control extra responsibility by orchestrating different I/O aspects • Hard to change • UI technology will change and we have too many things in that UI • Business/Flow will change and we still have too much in UI and DAOs (c) Copyright 2017 Valentin Tudor Mocanu 13

15. Some other solutions • Domain Model versus Transaction Script (Martin Fowler) • Logical limitation: Collaboration objects only at domain model level • “Layered class type architecture” from Scott W. Ambler “Building Object Applications That Work”: Interface, Process, Domain, Persistence, System. • A step forward • “Interface”: system interface is not only UI interface, but also web services and others • “Process” a start for describing the flow control at domain level • “Domain” – domain entities • “System” – wrapping OS specifics (c) Copyright 2017 Valentin Tudor Mocanu 15

16. How to find a solution that works • You need some problems to solve first  • Reuse industry experience (principles, patterns, examples) • Collaborate inside your teams, organizations, communities • Creatively apply design principles or patterns • … for creating new solutions • … for changing existing systems • … for making existing systems adaptable and paying technical debt (refactoring) (c) Copyright 2017 Valentin Tudor Mocanu 16

17. Refactoring ! • One of the main skills of a developer • Need practice: one module, more modules; thousand, ten of thousand lines of code or more • Build a design that works better for your context • Pay the technical debt • Do not forget refactoring specifics: small increments, test, restore the “green” quickly (c) Copyright 2017 Valentin Tudor Mocanu 17

18. Capability to change the system • Maintain the existent systems clean, easy to adapt and change • Pay the technical debt, • … but remember that too much debt with too late refactoring it is a waste • Misconception: change is a problem of older systems. Why? • New system are “changing” during development • Young systems require significant and quick changes • Be always prepared • To change technologies • To change business and flow • It is much better • to start clean • to maintain your system clean (c) Copyright 2017 Valentin Tudor Mocanu 18

19. Clean Systems and Quality • Lean thinking: defects are waste • You will have much fewer defects on clean systems • You will reduce complexity and interruptions • Test & fix systems with poor design cannot get good quality • You will test based on F/NF requirements • You will test expected states, flows, test cases • Poor design systems has much more (undesired) states, flows, test cases • Fragility • Clean systems are strategically testable • You will want to test concerns separately • Enable TDD (c) Copyright 2017 Valentin Tudor Mocanu 19

20. Ivar Jacobson BCE diagram • Category of classes • Boundary • Control: Flows & Rules • Entity • Symmetry ! - around flow control • Good start • Robert Martin started here • I have started here (... years later) • Too few guidance • See Biblio-B5 (c) Copyright 2017 Valentin Tudor Mocanu 20

21. My Journey • Use robustness diagram to imagine refactoring • Refactoring (a lot) • Observer: try to decouple UI from business • Question: how/what will be on “business side” of the observer? • My answers (~2003): • Flow control • Use Case Maps? No. Flow control can have more levels and common parts • UI, Logging, Network, Persistence have a similar treatment • Wow! My requirements are explicitly described in flow control classes (c) Copyright 2017 Valentin Tudor Mocanu 21

22. Confirmations When I found some industry validations of my choices • Universal Design Pattern (Koni Buhrer) ~ 2003/2004 • Blackboard Architectural Pattern (POSA) ~ 2007 • JEE Rethinking ~ 2009 • Hexagonal Architecture (Alistair Cockburn) ~ 2011 • Clean Architecture (Robert C. Martin) ~ 2012/2013 • Left-right asymmetry (Alistair Cockburn) ~ 2017 (c) Copyright 2017 Valentin Tudor Mocanu 22

23. Universal Design Pattern • Perfect symmetry • No discrimination between I/Os • Flow control – orchestrator role • Business processing/rules separately • I do not have uses the UDP passive “Data” approach • See Biblio-B2 (c) Copyright 2017 Valentin Tudor Mocanu 23

24. Clean Architecture – Robert C. Martin • Strategical separation of concerns • Entities • “Enterprise business rules” – domain/enterprise specific • Use cases • “Application business rules” – application specific flow • Interface Adapters • MVC is here • External/Internal data conversion • Frameworks and Drivers • Database, web frameworks • Circle shape • 4 circles just a simplification • Dependency – points “inwards” • See Biblio-B4 (c) Copyright 2017 Valentin Tudor Mocanu 24

25. Clean Architecture – Advantages • Strategical separation of concerns: support for testing them independently • Strategic support for TDD and for Integration Test First • We can defer building some aspects, according to our needs • Strategic support for changes • Technology changes • Related parts are separated from business and from each other. • Remember – technology will change more often these days • Functionality changes • Business is protected and decoupled • Flow could be changed independently of business rules • Overall better design & quality • Address rigidity and fragility (c) Copyright 2017 Valentin Tudor Mocanu 25

26. Retrospective: 2 Centers of Flow Control • Retrospective: Many (of my) implementations of for UI based modules have 2 centers for the flow control • One for orchestrating the user-interaction related flow • One for orchestrating the system resources related flow • Interesting! (c) Copyright 2017 Valentin Tudor Mocanu 26

27. Generalize • Generalize for any type of module • UI based • Background tasks • Online requests based • Hybrid • Symmetrical approach • It is working similarly if we need to manage similar flows for interaction ~ not dependent on interaction type (c) Copyright 2017 Valentin Tudor Mocanu 27

28. Generalize – Concept and Terms • Client Interaction vs Presentation • “Presentation” is just a particular case, when the client is a human user and the interaction support is the UI. We cannot offer a generic Architecture pattern describing only a particular case • System Resource Access (“Services”) vs Persistency • “Persistence” it just a particular case of accessing systems resources • Generic • Client Interaction “Layer” – a n-dimensional CA cell • System Resources Access “Layer” – a n-dimensional CA cell (c) Copyright 2017 Valentin Tudor Mocanu 28

29. Both Symmetrical and Asymmetrical • Symmetrical • Separate the concerns ~ Clean Architecture • Asymmetrical – 2 cells • 2 CA cells and not UI/Persistency axe • System interactions with its clients • Access to systems resources • Clients Interaction • Could be stateful • System Resources Access • It is rather stateless (c) Copyright 2017 Valentin Tudor Mocanu 29

30. Simplify/adapt in context • Sometime, in the context, we can simplify, if the flow is “flat” • Example • The client/actor is an internal timer. • When it is invoked a single resource access service, the interaction layer flow could be “flat”, and just redirect the call • Context matter for design optimization • When there are more resource access services are invoked and/or the client interaction flow it is more complex on orchestrating client, business, and services calls, we can use a full CA cell for interaction layer (c) Copyright 2017 Valentin Tudor Mocanu 30

31. Test support enhancements • Clean Architecture offer strategic support for test • Auto-test pattern – test concerns separately • We can plug test doubles (stubs, mockups, fakes) in the flow element • Dependency inversion help • 2 Cells Clean Architecture enhancements • Test client-interaction and system resources access separately • Each aspect has different requirements and test aspects • We can build one of them first and use test doubles for the other (c) Copyright 2017 Valentin Tudor Mocanu 31

32. Solution support enhancements • Test-first mindset • better support for test it is, in fact, better support for the realization • Examples – Client Interaction • Want to test performance, stress, loading • Realization/validation for memory support client interaction state • Examples – Client Interaction • Want to validate performance, concurrency for accessing system resources • Stateless-based realization/validation support for these services (c) Copyright 2017 Valentin Tudor Mocanu 32

33. Solution support enhancements - 2 • Consistent & Simple • System resources access • Can be designed in the same manner, independent of client (interaction) type • Client Interaction • Different interaction types, with different clients types, are designed in a similar way • Reusability • Same service or set of services for system resources access could be reused • in different modules with different client interaction types, • … or for creating “hybrid” components with more types of interaction: UI and Scheduling, or UI and networks • Example: A UI-based component could be easy transformed in a Scheduling-based component (c) Copyright 2017 Valentin Tudor Mocanu 33

34. Alistair Cockburn Asymmetry • Hexagonal Architecture • Similar to Clean Architecture • Created by Alistair Cockburn • “Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases.” • “When the application has something to send out, it sends it out through a port to an adapter, which creates the appropriate signals needed by the receiving technology (human or automated).” • Cockburn Asymmetry • Cockburn “The Left-Right Asymmetry”: <<in implementation, ports and adapters show up in two flavors, which I’ll call ‘’primary’’ and ‘’secondary’’ […] They could be also called ‘’driving’’ adapters and ‘’driven’’ adapters. >> • The reason/benefit invocated by Cockburn: testing purposes. Cockburn: <<fixtures are used on the left-side ports and mocks on the right >> (c) Copyright 2017 Valentin Tudor Mocanu 34

35. Alistair Cockburn Asymmetry – Update May 2017 • Some quotes from Alistair Cockburn, “Hexagonal Architecture”(See Biblio-B3) • <<… the asymmetry matches Ivar Jacobson’s primary and secondary actors concept>> • <<In implementation, that difference matters: Whomever will initiate the conversation must be handed the handle for the other.>> • <<In the case of primary actor ports, the macro constructor will pass to the UI, test framework, or driver the handle for the app and say, “Go talk to that”. The primary actor will call into the app, and the app will probably never know who called it. (That is normal for recipients of a call)>> • <<In stark contrast, for secondary actor ports, the macro constructor will pass to the UI, test framework, or driver the handle for the secondary actor to be used, that will get passed in as a parameter to the app, and the app will now know who/what is the recipient of the outgoing call. (This is again normal for sending out a call).>> • <<Thus, the system or application is constructed differently for primary and secondary actor ports: ignorant and initially passive for the primary actors, and having a way to store and call out to the secondary actor ports.>> (c) Copyright 2017 Valentin Tudor Mocanu 35

36. Differences: 2 ND layers CA and Cockburn approach • Asymmetry is not limited to ports • We divide the whole cell: application, adapters, ports and others; • The only common part remain the domain/business aspect • Flows are functionally different for different interaction types – visible and explicit • Extra Actors/Use Cases are not included by default • Split client interaction vs. system resources access does not create by default primary/secondary actors and/or use-cases • Primary/Secondary split for actors and use-cases are related to the functionality aspect • 2 cells splits it is related to the solution aspect • Only in some particular cases we can have the coincidence between 2 splits • Flow level differences are explicit • Flow is ignorant of who will trigger it: type of interactions (UI, scheduling, network) • Explicit and visible – flows have different forms in their instances for different interaction types • Test logic differences • Both interaction cell and resources access cell could have all kind of test doubles and text fixtures (c) Copyright 2017 Valentin Tudor Mocanu 36

37. Right Side – Any kind of test double • Stubs • Test doubles for services provides desired test inputs • Mockups • Test doubles allow checking how services are invoked from interaction layer • Fakes • Develop Interaction layer first (c) Copyright 2017 Valentin Tudor Mocanu 37

38. Left Side – More types of test doubles • Stubs • Test double for interaction provides services desired test inputs • Fakes • Develop “services” layer first, with fakes as test double for interaction (c) Copyright 2017 Valentin Tudor Mocanu 38

39. Final thoughts • Clean Architecture • Always was reliable and helpful • Support for changes: business or technology • Different names, same concept • 2 Cells Clean Architecture • Client Interaction + System Resources Access (“Services”) • This is it what I have used many times in practice • Depending on context, Interaction layer could be a full CA cell or a rather “flat” • Symmetrical, similar strategy for all types of interactions • System Resources Access (“Services”) – same approach for all types of components • Enhanced Support for: build & validate, test, reusability, consistency (c) Copyright 2017 Valentin Tudor Mocanu 39

42. Bibliography and References (B1) - “Layered class type architecture” from Scott W. Ambler • http://www.ambysoft.com/essays/classTypeArchitecture.html (B2) - Universal Design Pattern – by Koni Buhrer • http://www.ibm.com/developerworks/rational/library/content/RationalEdge/jan01/FromCraftToScienceJan01.pdf (B3) - Hexagonal Architecture – by Alistair Cockburn • http://alistair.cockburn.us/Hexagonal+architecture (B4) - Clean Architecture – by Robert C. Martin • https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html • .. and check for coming soon book “Clean Architecture”! (B5) – The UML Reference Manual • Addison Wesley, By Ivar Jacobson, Grady Booch, James Rumbaugh (B6) – Demanding • https://www.youtube.com/watch?v=p0O1VVqRSK0 (by Robert C. Martin) (c) Copyright 2017 Valentin Tudor Mocanu 42

Enhancing clean architecture: 2 n-dimensional layers

Valentin-Tudor Mocanu

Enhancing clean architecture: 2 n-dimensional layers