Agile Architecture: Enhancing Clean Design

Enhancing Clean Architecture:
2 N-Dimensional Layers
A roadmap to Agility
(c) Copyright 2017 Valentin Tudor Mocanu 1

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”.

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.

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.

According to Robert C. Martin, this is the second main responsibility of a programmer
Which is then the first responsibility of a programmer?

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)

We like to present our design as:
• Layered Architecture
• Component based
• MVC and similar
• Framework based
• Based on newest technologies

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

What if we can do our job right?

Layered Architecture
• Finally, some order in the chaos!
• UI decoupled from the business
• Persistence decoupled from the business

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

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

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

We need something else!

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

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)

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

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

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

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

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

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

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

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

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

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!

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

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

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

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

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

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

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

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 >>

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.>>

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

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

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

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

QUESTIONS?

Info
valentin [at] valentinmocanu.com
@ValentinTudor
agiledesign.org
agileand.blogspot.com

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)

Agile Architecture: Enhancing Clean Design

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (18)

Similaire à Agile Architecture: Enhancing Clean Design

Similaire à Agile Architecture: Enhancing Clean Design (20)

Dernier

Dernier (20)

Agile Architecture: Enhancing Clean Design