5. What is your architecture making obvious
“I am an ASP MVC app? I have controllers and views!”
Or
“I am an online music catalogue, A payroll system, etc“
Make it shout about the problem domain not the framework.
6. What’s in a screaming name?
I don’t like this name.
The architecture should not be wailing in
pain, it should be running smoothly.
Is there a better name for this idea?
7. How about…
• Obvious architecture
• Blatant domain
• Lucid domain architecture
• The “what are you making plain?” principle
• Putting related stuff together and naming it well
• Feature folders?
8. Feature folders
This is a broad idea. Narrow our focus!
“obvious architecture” idea implies that code should be arranged
with related code for a feature in the same folder.
9. How?
In ASP MVC
You need a custom controller locator and custom view locator.
Good news for the controller locator:
Your Ioc Container can do it.
Not as good news for the view locator. You need some custom code.
Demo In Visual studio…
10. In ServiceStack or Nancy
These frameworks support feature folders without customisation.
Just do it.
Demo In Visual Studio
11. Repositories / Data Stores / Services
• Still have a “data layer” where access to DB/ Web services becomes
the main concern.
• Split at this boundary where the concerns, dependencies change
• Vocabulary of tests change at the boundary too.
• But inside that project, still have related stuff together.
12. In Angular
• Even further integrated by feature:
• 2 levels of tests live in with the js “codebehind” and the html markup.
• The build process does different things with them.
Sublime text demo
13. Conclusion
• Some things can easily be found by the tooling
• But the problem domain can’t
• Make that explicit
• Put conceptually related things together
