Graduate Program KB

Domain Driven Design

Chapter 4 - Isolating the Domain

  • The domain is the problem space in which we are solving our problem
  • The domain model represents a small part of the program in which our problem is actually solved
    • A model is made up of domain objects, handling the behaviour of a component within the model
  • We must decouple domain objects from separate functions of the system
    • Avoid losing sight of the domain / problem space
    • Don't want to confuse different domain concepts
  • The goal is to isolate the domain from other parts of the system while maintaining interactions within
    • Difficult to see business rules / domain implementation since a lot of components (UI, database, business logic) are diffused throughout the code

Layed Architecture

  • The standard layers that isolate parts of the system, it creates a more cohesive design that can be easily interpreted
  • Any element of a layer depends only on other elements in the same layer or layers beneath it
  • Each layer specialises in a particular aspect of the program

The Standard 4 Layers

  • User interface: Sharing information to the user
  • Application layer: Define jobs software does at a high level
  • Domain layer (model layer / core domain): Business rules and concepts
  • Infrastructure layer: Technical aspects that support the higher layers

Relating the Layers

  • Layers must be isolated but loosely connected, the dependencies should only flow downward
    • Higher layers can manipulate lower level elements through interfaces
  • How to communicate upwards?
  • A popular architecture is Model-View-Controller (MVC)

Architectural Frameworks

  • The best frameworks solve complex technical problems but allow the developer to concentrate on expressing the model
  • However, frameworks can often be heavyweight which slows development down
    • Can be solved by applying frameworks selectively

The Smart UI "Anti Pattern"

  • Steps:
    • Put all business logic into the UI
    • Split application into small functions and implement as separate UIs, embedding the business rules into them
    • Use a relational database as a shared data repository
    • This method goes against domain driven design, hence, an anti-pattern
  • Uses:
    • For teams unfamilar with domain modelling, modelling well is a steep learning curve
    • For small and simple projects that don't emphasise on modelling techniques that would only slow the team down
    • Domain driven design is useful for complex projects that need to be scalable and maintained
  • Advantages:
    • Immediate productivity for simple applications
    • Beginner developers can begin working with little experience
    • Develop and release a quick prototype then iterate based off feedback
    • Maintenance programmers can quickly redo components as the modules are small and logic is localised to a specific UI
  • Disadvantages:
    • Integration of applications is difficult except through the database
    • No reuse of behaviour and no abstraction, lots of duplication
    • Prototyping will eventually become slow due to lack of abstraction and refactoring options
    • No way to implement more richer behaviour as complexity will grow quickly