Choosing the right software architecture for your project is very important. Besides the framework decision there are many other key issues you need to take into account and which have an impact on such things like maintainability, scalability and also the frequency of possible deployments. In this session you will to learn how to avoid the common pitfalls and traps during your project.
2. Lars Jankowfsky
• CTO and (Co-)Founder swoodoo AG
• (Co-)Founder OXID eSales AG
• XP, agile development fanatic
• developing since 15+ years
• php since php/fi
• Software Architect > 10 years
Lars Jankowfsky,
14. „For us, it’s really about scaling horizontally - to that end,
Rails and Ruby haven’t been stumbling blocks, compared
to any other language or framework. The performance
boosts associated with a “faster” language would give us a
10-20% improvement, but thanks to architectural changes
that Ruby and Rails happily accommodated, Twitter is
10000% faster than it was in January.“
Blaine Cook, Twitter's lead architect
Lars Jankowfsky,
30. Bad smells?
• Do maintenance cost keep increasing?
Lars Jankowfsky,
31. Bad smells?
• Do maintenance cost keep increasing?
• Simple features need too long to be implemented
Lars Jankowfsky,
32. Bad smells?
• Do maintenance cost keep increasing?
• Simple features need too long to be implemented
• Small changes ripple through your system
Lars Jankowfsky,
42. Layered Architecture
• separation of concerns
• If they can live without each other - why to couple
them?
Lars Jankowfsky,
43. Layered Architecture
• separation of concerns
• If they can live without each other - why to couple
them?
• Find the boundaries and cut mercilessly.
Lars Jankowfsky,
44. Layered Architecture
• separation of concerns
• If they can live without each other - why to couple
them?
• Find the boundaries and cut mercilessly.
• Do not bypass any layer!
Lars Jankowfsky,
45. Layered Architecture
• separation of concerns
• If they can live without each other - why to couple
them?
• Find the boundaries and cut mercilessly.
• Do not bypass any layer!
• Separate modules/classes or go SOA
Lars Jankowfsky,
47. SOA
• Pro: makes scaling very easy
Lars Jankowfsky,
48. SOA
• Pro: makes scaling very easy
• Pro: clear defined boundaries, no violations possible
Lars Jankowfsky,
49. SOA
• Pro: makes scaling very easy
• Pro: clear defined boundaries, no violations possible
• Pro: perfect for refactoring
Lars Jankowfsky,
50. SOA
• Pro: makes scaling very easy
• Pro: clear defined boundaries, no violations possible
• Pro: perfect for refactoring
• Pro: Deployment benefits
Lars Jankowfsky,
51. SOA
• Pro: makes scaling very easy
• Pro: clear defined boundaries, no violations possible
• Pro: perfect for refactoring
• Pro: Deployment benefits
• Con: integration testing gets more difficult
Lars Jankowfsky,
58. Database
• you might use a database access layer
Lars Jankowfsky,
59. Database
• you might use a database access layer
• go ORM if you want (performance!)
Lars Jankowfsky,
60. Database
• you might use a database access layer
• go ORM if you want (performance!)
• business layer - not abstraction layer
Lars Jankowfsky,
61. Database
• you might use a database access layer
• go ORM if you want (performance!)
• business layer - not abstraction layer
• let‘s call it Data Access Object
Lars Jankowfsky,
68. Controller
• Common mistake: business logic in controller
Lars Jankowfsky,
69. Controller
• Common mistake: business logic in controller
• Keep it out! Otherwise you will end with SQL in
controller
Lars Jankowfsky,
70. Controller
• Common mistake: business logic in controller
• Keep it out! Otherwise you will end with SQL in
controller
• I/O mapping to the model and view only
Lars Jankowfsky,
71. Controller
• Common mistake: business logic in controller
• Keep it out! Otherwise you will end with SQL in
controller
• I/O mapping to the model and view only
• Kick Ass!
Lars Jankowfsky,
102. Project structure
• Remember? Find Boundaries and cut.
• quot;Services/Layersquot; - at least on a directory level
• use Framework structure
• more ???
Lars Jankowfsky,
\"if you want to serialize to xml do not create \"toxml\" Method, instead pass $this to the XMLExporter\"
think in advance but don‘t think too complex
before making any generalisation have at least two cases
the more abstractions the easier you can change it later
nobody said it will be easy
tightrope walk
preparing fixtures/Mocks difficult
preparing fixtures/Mocks difficult
preparing fixtures/Mocks difficult
preparing fixtures/Mocks difficult
preparing fixtures/Mocks difficult
do not spread db calls through your code
one function or object generates one „business“ result
data access object
do not spread db calls through your code
one function or object generates one „business“ result
data access object
do not spread db calls through your code
one function or object generates one „business“ result
data access object
lazy loading ok
in Ruby all Variables from controller are accessable.
lazy loading ok
in Ruby all Variables from controller are accessable.
lazy loading ok
in Ruby all Variables from controller are accessable.
Do not reinvent the wheel. Use frameworks
at least daily
test a single class
do not touch database, network, (files)
use mocks/stubs and provide fast feedback
test several classes
test communication between classes/modules
they test full components
test functionality from „outside“
often build from „user stories“
usually done with Selenium -> not only selenium example openapi