Isolating the Domain

• Software is written to solve a problem

• The Domain is the problem space in which we are solving our problem

• Our Domain Model represents a small part of the program in which our problem is actually solved

• Domain objects make up the domain model. These objects handle the behaviour of a section of the Domain Model

• We must look at the elements of the model and see them as a system

• To apply our best thinking we must decouple the domain objects from the other functions of the system to avoid losing sight of the domain (problem space) altogether

• We do not want to easily confuse domain concepts with other concepts related only to the software technology

• When we lose sight of the domain or problem space we can't identify if our model actually solves the problem

The issue with object oriented programming and domain modeling

• The UI, database and other support code all get written into business objects, meaning Domain related code gets diffused through a large amount of other code
• It is very difficult to see business rules / domain related code

Our goal is to isolate the domain from the other parts of the system while maintaining interactions within the system

Layered Architecture

• Defined standard layers that isolate parts of the system
• Principle: Any element of a layer depends on only other elements in the same layer or on elements of the layers beneath it The Value of Layers
• Create for more cohesive design
• Each layer specializes in a particular aspect of the program
• Layers make for the intended design to be easily interpreted

The Standard 4 Layers

• User Interface:
  • Sharing information to the user
  • Interprets user commands
• Application Layer:
  • Defines the jobs the software is supposed to do at a high level
  • Delegates work to collaborations of domain objects
• Domain Layer (Model Layer / Core Domain):
  • Represents concepts of the business, information about the business situation and business rules
  • All technical details are delegated to the infrastructure layer
• Infrastructure layer:
  • Provides generic technical capabilities that support the higher layers

Relating the Layers

• The motivation behind many different patterns is how to maintain connection between layers
• Layers must be isolated but still connected (loosely coupled), with design dependencies in only one direction (Downward)
  • Upper layers can use or manipulate elements of lower layers by calling their public interfaces
• Issue is how do lower levels communicate upwards
• Popular architecture is the Model View Controller
  • Layers seperated into the model, view and controller
  • The controller acts as a bridge between the model and the view
• There are many other variations on this architecture

Architectural Frameworks

• The best frameworks solve complex technical problems while allowing the domain developer to concentrate on expressing a model
• Frameworks can often get in the way of development
  • Some make assumptions that constrain domain design
  • Some have implementation that is so heavyweight the development slows down
• However, a lot of the downsides of frameworks can be avoided by appling them selectively
  • Choose a framework that suits the goal of building an implementation that expresses the domain model
  • Only apply the most valuable framework features to reduce coupling of the framework and the implementation
• These allow for more flexibility in later design decisions

The Smart UI "Anti Pattern"

• The seperation of UI, Application and Domain is seldom accomplished
• We want to rather use a less sophisticated design approach

Steps of the Smart UI pattern:

1. Put all the business logic into the user interface
2. Chop the application into small functions and implement them as seperate user interfaces, embedding the business rules into them.
3. Use a relation database as a shared repository of the data

• The smart ui pattern goes completely against domain driven design, hence the name 'anti pattern'

Use of the Smart UI Pattern

• This pattern is for teams that are unfamiliar with domain modeling.
  • Learning to model well is a steep learning curve.
• The smart ui 'anti pattern' is also only to be used for small simple projects that do not need the overhead of DDD
  • Seperating and maintaining layers using modeling techniques would slow down a team working on a small project
• Domain driven design pays off on ambitious / complex projects with experienced developers

Advantages

• Productivity is high and immediate for simple applications.
• Less capable developers can work this way with little training.
• Even deficiencies in requirements analysis can be overcome by releasing a prototype to users and then quickly changing the product to fit their requests.
• Applications are decoupled from each other, so that delivery schedules of small modules can be planned relatively accurately. Expanding the system with additional, simple behavior can be easy.
• Relational databases work well and provide integration at the data level.
• 4GL tools work well.
• When applications are handed off, maintenance programmers will be able to quickly redo portions they can't figure out, because the effects of the changes should be localized to each particular UI.

Disadvantages

• Integration of applications is difficult except through the database.
• There is no reuse of behavior and no abstraction of the business problem. Business rules have to be duplicated in each operation to which they apply.
• Rapid prototyping and iteration reach a natural limit because the lack of abstraction limits refactoring options.
• Complexity buries you quickly, so the growth path is strictly toward additional simple applications. There is no graceful path to richer behavior.