Long-life systems
Did you known that some systems lifes more than one year?
Few facts about our application
-
Have worked on PRD from five years
-
Main booking engin to sixty tourist agency
-
44,000 lines of production code in C#
-
18,000 lines of production code in Javascript
-
1,200 tests
-
40 releases
-
Integrate about 10 subsystems
Do you remember Bob the Builder?
A lot of us seems to like Bob’s approach.
-
Starts working with legalcy system
-
Complains on it
-
Deside to build the same system from the beginning
-
Makes few things better
-
Start to belive in “steel” design and lost big picture
-
After some time the system looks like the old one
Architecture Evaluation
Good architectural design is not only a good project. Good project is just the beginning, you must think about architectural design all the time.
Architecture Evaluation
Even well working system can be easy break.
Architecture Evaluation
Evan weak system can become strong.
What we got in our application
-
Big Ball of Mud
-
Transaction Script
-
No logic and infrastructure separetion
-
No any kind of dependency management
-
A lot of code duplication
-
Javascript as one big ani pattern
In other words:
fragility + no test = disaster!
What pushed us into changes
-
Low level of system reliability
A lot of opened issues and bugs.
-
Updates take so long time
In some cases it can take even one day and fail
-
No any kind of automatic builds
Very hard to create new system instance
-
At least few years system maintenes perspective
System reminds marathon man after marathon although marathon still go on
-
System development
New requests from our clients and new clients still required system development
First steps
-
First unit tests
-
Cleaning useless code
-
Dupication code resolving
-
-
First attempt to layer isolation
-
First entry to client side( Dark World of Javscript)
Things are starting to gel
Composite and MVP pattern in Javascript
|
|
- Every HTML elements can contains other elements - excellent example of composite pattern.
- Every element has distinct role, however each element is builds with the same parts:
- We have part responsible for HTML - View
- We have part responsible for a data - Model
- We have part responsible for UI logic -Presenter
- Model is not related with View neither Presenter
- Every element exist in isolation
|
What we achieve on the client side?
-
Basic division of Responsibility
-
Possibility of bug fix without text parser :)
-
Module reusability
-
Development new feature without risk of breaking old ones
Dependency Injection & Loose Coupling
-
TDD and unit tests were like first sign of DI
-
Dependency management - not necessary external complex and heavy framework
-
Step by step involve new system areas
-
A lot of effort to isolate from external components
Domain Driven Design
-
Upside-down
-
Focusing on domain not on infrastructure
-
Infrastructure not deside about domain.
-
Domain not tools or frameworks decide about design
-
Application like a domain description
-
System built on domain is more flexible for requirements changes
First sings of system architecture
-
-
Additionaly in frontend layer appears new factors
- Quick development and changes in external libraries
- Global dev community start taking Javascript seriously as a language
- Requests from clinets - big pressure on experience
- Client side MVP becomes not sufficient - new layers appears on the client
Where we are now
Back-end flavour onion
Front-end flavour onion
Bibliography:
-
Jimmy Nilsson. Applying Domain-Driven Design and Patterns: With Examples in C# and .NET
-
Robert C. Martin. Agile Principles, Patterns, and Practices in C
-
http://jeffreypalermo.com/blog/the-onion-architecture-part-1/
-
http://martinfowler.com/eaaDev/uiArchs.html
-
http://www.slideshare.net/nzakas/scalable-javascript-application-architecture
/
#