Brand new fancy frameworks appear quite often nowadays. Sometimes we as developers are trying to keep up to date by blindly chasing them. But is the investment worth? What business expects from us? Fancy frameworks or solid delivery pipeline? How can we focus on writing line of business code? How can we postpone architectural decisions about frameworks? How to make sure that your project structure reflects the business, not the technical brainfuck? Artur has been digging this topic for years and has a lot of real-life examples to share. Artur is a seasoned, independent consultant, who went through enterprise applications of all kinds. He is enthusiastic about building and leading strong teams, revealing their potential and making smart people working with other smart people.Artur’s peers know how pragmatically he combines business-oriented thinking and fanatic passion for software development best practices like Domain-Driven Design, TDD, paired programming, writing clean code, etc. Before he went independent, he worked as an architect and a tech lead. In addition to that Artur is an active OSS contributor and blogs at Craftsman at Work.

1. Arturs Karbone
22-Feb-2018
USE-CASE-DRIVEN ARCHITECTURE
https://www.linkedin.com/in/arturkarbone/
Blog http://craftsmanatwork.guru/
Training http://devchampions.com/training/unit_and_integration_testing/

2. THEY ARE KIND OF ABOUT THE SAME
• Architecture in Slices (J. Bogard)
• Screaming/Clean Architecture (Uncle Bob)
• Feature-Driven/Use-Case-Driven (A.Karbone & friends)
• Architecture of common sence (A.Karbone & friends)

3. THE TYPICAL SOLUTION I SEE. 1ST ISSUE
• Includes 30+ projects
• 159 projects per solution (personal records)
• Projects named: *.DALs, *.BALs, *.Helpers,
*.Services,*.Common, *.Migrators of any kinds
• Build & Run from F5 or a single script ? Forget about it
• Sane Development Practices?

4. THE TYPICAL PROJECT STRUCTURE I SEE. 2ND ISSUE
• Controllers
• Views
• Models
• Managers
• Services
• Interfaces (of course)
Where is freaking entry point? Where should I start?

5. THE TYPICAL TREND I SEE. 3RD ISSUE
• Fancy frameworks at 1st place
• Business at 2nd (my very OPTIMISTIC opinion)
• «Button» thinking

6. BUILDING ARCHITECTS SOLVED THIS PROBLEMS

7. CAN SOFTWARE ARCHITECTURE SCREAM ABOUT THE INTENT?
I think so

8. CAN SOFTWARE ARCHITECTURE SCREAM ABOUT THE INTENT?

9. ANATOMY OF BUSINESS PROCESS
• Input data
• Actions
• Results

10. ANATOMY OF USE-CASE

11. ANATOMY OF USE-CASE

12. ONE LINERS IN CONTENT DELIVERY MECHANISMS

13. LOB APPLICATION STRUCTURE = USE-CASES + CONTENT DELIVERY MECHANISMS

14. ROLES
• Use cases reflect business logic
• Content Delivery channels – oneliners calling use cases

15. IDEAL NUMBER OF PROJECTS IN THE SOLUTION
• One for all the Use Cases
• One per a Content Delivery channel

16. BENEFITS
• Business logic in one place
• Wrap use case with an additional cross-cutting logic
• Logging
• Performance Logging
• Wrap with additional context (Autofac/Correlation
ID for Masstransit Consumers)

17. TAKEAWAYS
• Focus on what matters
• We still have to follow frameworks trend (unfortunatelly)
• PhD in Getting Shits Done
• Business thinking via Use-Cases/Features
• It was possible to write this way 20 years ago
• It will be actual in 20 years
• Ship it!

18. RESOURCE
• SOLID architecture in Slices –
https://vimeo.com/131633177
• .NET Rocks! Fighting the Churn with Uncle Bob

19. QUESTIONS & DISCUSSIONS