1.
Nina Grantcharova
ngrantcharova@limra.com
Approach to Separation of Concerns
via Design Patterns

2.
Separation of Concerns Principle
 Comprises the process of separating a system into distinct
parts that adhere to a single and unique purpose.
 Aims at managing complexity by establishing a well-
organized system
 Achieved by establishing boundaries

3.
Value
 Increased
 Maintainability
 Reusability
 Extensibility
 Customization
 Testability
 Stability
 Productivity

4.
Techniques and Concerns
 Techniques:
 Layers
 Modules
 Aspects
 Subjects
 Extensions
 Concerns:
 Data
 Behavior
 Dependency

5.
Layered Architectural Style
Focuses on the grouping of related functionality into distinct
layers
Functionality within each layer is related by a common role or
responsibility
Communication between layers is explicit and loosely coupled

6.
The three principal layers
 Presentation: External interface of a service the system
provides to someone else, whether human or remote system
 Data Source: Interface to things that provide service to the
system
 Domain: Logic that is the real point of the system

7.
Layer Separation
 The level depends on how complex the application is
 Dependency rule: The domain and data source layer
should never depend on the presentation
 Logic placement test: Imagine replacing your
presentation with a different type of presentation

8.
Modules
 Divide the system in units of functionality along logical
boundaries that relate to the same feature or sub-system

9.
Aspects
 Aspect-oriented programming entails breaking down
program logic into distinct parts called crosscutting concerns

10.
Subjects
 Subject-Oriented Programming is the process of program
composition that supports building object-oriented systems
as compositions of subjects, extending systems by composing
them with new subjects, and integrating systems by
composing them with one another.
 Subject-oriented programming-in-the-large involves dividing
a system into subjects and writing rules to compose them
correctly. It complements OOP, solving a number of
problems that arise when OOP is used to develop large
systems or suites of interoperating or integrated applications.

11.
Extensions
 Enable addition of new behavior to existing system

12.
Design Patterns
 Common solutions of recurring problems in a given context
 Rooted in practice
 Broad-brushed pictures
 Relatively independent but usually used in groups
 Define vocabulary about design

13.
Credits
 “Patterns of Enterprise Application Architecture” , Martin
Fowler
 “Design Patterns”, GoF
 “SOA Design Patterns”,Thomas Earl

14.
Separated Interface
very simple to employ
split interface and
implementation in separate
packages
other packages depend on
the interface
palace the interface in the
client package or separate
package
Defines an interface in a
separate package from its
implementation.

15.
Organizing Domain Logic
 Transaction Script
 Table Module
 Domain Module
 Service Layer

16.
Domain Model
 An object model of the domain that incorporates both
behavior and data

17.
Strategy
 the behaviors are encapsulated, not inherited
 aggregation instead of inheritance.
 decoupling between the behavior and the class that uses it
 Open/Closed Principle (OCP)

18.
How and When to Use
 A layer of objects that models the business area
 Has objects that mimic the data and objects to capture the
rules
 Mingles data and processes, have complex web of
associations, uses inheritance
 Two types:
 Simple – mimics the database, one object per table.
 Rich – different from database, inheritance, strategies and
other GoF patterns. Requires Data Mapper
 Common concern is bloated objects. Object like Order can
have so much behavior that it's too big, including behavior
that is used in single case scenario

19.
Service Layer
 Defines an application's boundary with a layer of services that
establishes a set of available operations and coordinates the
application's response in each operation

20.
How and When to Use
 Encapsulates the application's business logic
 Controls transactions
 Coordinates responses
 Two kinds of business logic:
 domain logic: deals purely with the problem domain
 application logic: deals with application
responsibilities
 Bloating
 Remoting concerns

21.
Service Encapsulation
How can solution logic be made available as a resource
of the enterprise?
 Solution logic designed for a single application environment
is typically limited in its potential to interoperate with or be
leveraged by other parts of an enterprise.
 Solution logic can be encapsulated by a service so that it is
positioned as an enterprise resource capable of functioning
beyond the boundary for which it is initially delivered.

22.
Service Façade
How can a service accommodate changes to its
contract or implementation while allowing the core
service logic to evolve independently?
 The coupling of the core service logic to contracts and
implementation resources can inhibit its evolution and
negatively impact service consumers
 Facade logic is placed in between the contract and the core
service logic

23.
Data Transfer Object
 An object that carries data between processes in
order to reduce the number of method calls

24.
How and When Use
 Aggregates data from all objects that the remote process may
need. Exists on both sides of the wire.
 DM – web; DTO - simple hierarchy
 DM does not need to exist on the client
 Fields in DTO are primitive, serializable types
 Designed around the need of a particular client
 DTO is not aware of the DM
 Assembler is responsible for creating DTO from DM and
updating the model from it.
 Assembler is an example of Mapper between DTO and DM

25.
Subjects

26.
Plugin
 Links classes during configuration rather than
compilation.

27.
Factory
Define an interface for creating an object, but let the
classes that implement the interface decide which class
to instantiate

28.
How and When to Use
 Eliminates the needs to bind application classes into your
code.The code deals with interfaces so it can work with any
classes that implement a certain interface.
 Enables the subclasses to provide an extended version of an
object, because creating an object inside a class is more
flexible than creating an object directly in the client.
 When a class cannot anticipate the class of objects it must
create.
 When a class wants its subclasses to specify the objects it
creates.
 Classes delegate responsibility to one of several helper
subclasses, and you want to localize the knowledge of which
helper subclasses is the delegate.

29.
Layer Supertype
 A type that acts as the supertype for all types in its
layer.
 It's not uncommon for all the objects in a layer to have
methods you don't want to have duplicated
throughout the system. You can move all of this
behavior into a common Layer Supertype.

30.
Questions?

31.
Thank you!