Container Coding

In this talk “Container Coding”, a term I have never heard before is used as a way of describing a group of design patterns which are structural in nature and serve to create greater separation of concerns within your application. I was already familiar with most of these concepts but I think Patrick did a good job of summarizing them. Being familiar with the topics already I would have liked more PHP specific examples, but that is just me and wouldn’t be for everyone. I would probably attend another talk by Patrick in the future.

Below are my notes for this talk:

---

“Old School PHP”

• no/minimal code structure
• no separation of concerns
• code is typically procedural (not OO)

What is “Domain Logic”?

• A set of rules that defines:
• The different types of “things” that your software cares about
• How the “things” relate to each other
• What processes and workflows are allowed in the system

Bring in the MVC pattern

• Model, View, Controller
• Domain logic exists in the model
• Avoid putting domain logic into the controller

What’s in the model?

• At this stage, Table Modules
  • One class per table with all logic to fetch/update data
  • One instance per invocation
  • Each class can only do single table operations

Scorecard: MVC

• Improvements: Controller and View don’t need to care how tax is calculated. Reduced time to plan and implement
• Problems: Domain logic is still intertwined with persistence (database) logic. testing is still difficult

Domain lay vs serv lay

• service lay
  • unified mains of accessing business logic
  • includes some application logic for accessing things
• domain lay
  • representation of our bus log
• Patterns of Enterprise Application Architecture by Martin Fowler

Scorecard: Service / Domain Layer

• Improvements:
  • service layer can be tested in isolation (by mocking domain layer). reduced testing time, improve testing reliability
  • complete extraction of domain logic from controllers. reduce planning and implementation time
• Problems:
  • domain layer still mixes persistence with domain logic
  • domain log cannot be tested in isolation from persistence layer (database)

ORM to the Rescue

• Object-relational mapping (ORM) replaces table modules with entities
• Doctrine 2 ORM is a PHP implementation
• Entities
  • plain old PHP objects
  • don’t directly access databases
  • entity logic can easily be tested in isolation

Scorecard: ORM

• Improvements:
  • complete separation of domain logic and persistence logic. reduce testing time, improve testing reliability
  • changes to the domain logic (typically) require updates in a smaller area of code. reduce planning and implementation time
• Problems
  • learning curve for ORM
  • data architecture must conform to ORM
  • Some negative performance impact, limited opportunities to optimize

Service-Oriented Architecture

• Instead of the service layer relying on the Domain layer the service layer works with service clients which are essentially applications of their own.

Scorecard: Service-Oriented Architecture

• Improvements:
  • Designing to API simplifies definition of test cases and creation of test mocks. reduced time creating test, improved test reliability
  • services can serve many different clients
  • Opportunities to scale the development teams (separate ownership of services)
  • Service can be implemented with whatever language/technology that is best suited for it’s needs
• Problems:
  • coordination between apps and services (and their owners)
  • network overhead

Takeaways

• plan for change
• Manage technical debt – stay on top of issues
• More structured code == more maintainable code
• increasing application size requires increasing separation of concerns