Pragmatic Architecture

1. By Bob Bunson rbunson@munichreamerica.com Pragmatic Architecture

2. Software Architecture is…

3. The Approach • Simulation of software development project • Fictitious system from Concept to Code • Oriented around the software architect • The purpose of this exercise is to demonstrate: • Architecture considerations • Architecture activities • The realization of architecture in code

4. Roles • My role • Architect • Your candidate roles • Architect reviewer • Architect apprentice • Coder on future iterations • Passive observer

5. What I* mean by Architecture • The critical decisions that define a system • The decisions that are hard to change *By “I”, I really mean the actual thought leaders in the industry

6. Tax Calculator - Business Requirements • Produce a free tax calculator so that people can compute their taxes, plus their late penalties, so that they can pay the IRS

7. Tax Calculator - Non-Functional Requirements • Design for testability • Run on all modern browsers • Maintainability Productivity should not decrease as the application grows • All errors logged • High performance All pages should display in .6 seconds • Simple enough to demonstrate

8. Brush up on Architecture

9. Tax Calculator - Architecture Principles • Interesting, but small • No technology distractions • Interoperability

10. Tax Calculator - An Expanded Principle No Technology Distractions • Statement • During a presentation on basic application architecture, the introduction of new or trendy technologies should be avoided • Rationale • New, trendy, or controversial technologies has the potential to distract the audience and potentially impede the presenter from communicating about the foundations of architecture • Implications • Increased focus on the primary topic • Lost opportunity to learn a new technology in preparing for the presentation

11. Tax Calculator - Architecture Constraints • All ETL must use SQL Server Integration Services • .NET platform • Coding based on Microsoft naming conventions and “Clean Code” guidelines

12. Tax Calculator - Risk Assessment • Congress will change the tax laws retroactively prior to the presentation • Internet could be unreliable during this presentation • Web Forms and Test Driven Development don’t work well together

13. Risk Management Principles • Open communication • Integrated with the audience

14. Tax Calculator - Risk Management Strategy • “Web Forms and TDD causes too much friction” • Microsoft created ASP.NET MVC for a reason • To mitigate, create a prototype to evaluate the ease and intuitiveness (avoid the need to be clever and creative) of writing tests and code

15. Tax Calculator - Prototyping • Goals • Explore variations of the model-view-presenter pattern (Supervising Controller, Passive View) • Introduce a few anticipated scenarios such as working with Session State

16. Prototyping • Why • Mitigate risk • Communicate concepts • Understand technology • What • Throw away • Evolutionary

17. Architecture Patterns • Web Presentation Patterns • Model View Controller • Model View Presenter • Page Controller • Domain Logic Patterns • Transaction Script • Domain Model • Table Module

18. Tax Calculator – Architecture Tradeoffs • “Design for Testability” vs. “No Technical Distractions” • ASP.NET MVC better for testability • But would violate principle of “No Technical Distractions” • “Performance” vs. “Simple Enough to Demonstrate” vs. Usability • AJAX would improve performance and user experience, but would • Add to the complexity of the system

19. Tax Calculator – Technology Selections • ASP.NET Web Forms • Nunit • Visual Studio Web Server • Windows Vista • WatiN for Acceptance Testing

20. Tax Calculator – Key Design Decisions and Justifications • Use of ASP.NET Web Forms over ASP.NET MVC • Supports principle of “No Technology Distractions” • Use of NUnit over MSTest • Would get kicked out of Alt.Net if I used MSTest • Domain Model over Dataset • Preference of a domain model which encapsulates behavior and data to support potentially complex tax calculations over DataSets • More easily testable

21. Tax Calculator – More Key Design Decisions • Model View Presenter • Desire to keep behavior out of code-behind to support principle of Testability • Introduce Rhino.Igloo open source tool to abstract HTTP Context for easier testing • Prototyping uncovered obstacles associated with creating unit tests without dependencies on Session, Request, Response, etc.

22. Modeling with UML

23. Why Model Martin Fowler: • UML as Sketch • UML as Blueprint • UML as a Programming Language • Reverse Engineering • Forward Engineering

24. Tax Calculator – Class Diagram

25. No Best Practices • Context • Tradeoffs, constraints, and the real world exist • Effective architecture • Factors in context • Applies patterns when they apply • Leverages experience (own and others) There is no ideal best architecture

26. Tax Calculator – Aspects of Code Discussion • Realization of the software architecture in code • Testability of the layers • Object oriented principles in practice • Few thorny topics • Prioritized until we run out of time • Give “architect reviewers” something to do when the code falls short in any area

27. Tax Calculator – Code Preview • Testing • Readable, descriptive tests • Arrange, Act, Assert • Test Doubles – visualize where a mocking framework might help • Differentiate between unit tests and acceptance tests

28. Tax Calculator – Code Preview • Application • Dependency Injection - visualize where an Inversion of Control container might help • Model View Presenter • Domain model • Validation • Error Handling • Layer super types • Testable code

29. Tax Calculator – Code Preview • UI can also support architecture principles • Separation of Concerns: HTML and CSS • Maintainability: Master page, Layer super type • Interoperability: XHTML • User Experience: At least the potential of