Container Coding

Do you have to spend hours wrapping your head around your entire application before you can make simple changes to one part? Is each layer too reliant on other layers so each change is a major revision? You need container coding. Learn to segregate each layer of your code so you can deal with each individually. Your code will be flexible, easy to maintain, and ready for new features.

Joind.in Page – Slides

Patrick Schwisow @pschwisow Software Engineer, Shutterstock

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

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