Embed Size (px)
DESCRIPTION
Separation of Concerns aims at managing complexity by establishing a well-organized system where each part adheres to a single and unique purpose while maximizing the system's ability to adapt to change and increasing developers' productivity. The goal of this presentation is to promote the understanding of the principle of Separation of Concerns and to provide a selected set of foundational patterns to aid software architects in the designing of maintainable and extensible systems.
Citation preview
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
Value
Increased
Maintainability
Reusability
Extensibility
Customization
Testability
Stability
Productivity
Techniques and Concerns
Techniques:
Layers
Modules
Aspects
Subjects
Extensions
Concerns:
Data
Behavior
Dependency
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
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
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
Modules
Divide the system in units of functionality along logical
boundaries that relate to the same feature or sub-system
Aspects
Aspect-oriented programming entails breaking down
program logic into distinct parts called crosscutting concerns
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.
Extensions
Enable addition of new behavior to existing system
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
Credits
“Patterns of Enterprise Application Architecture” , Martin
Fowler
“Design Patterns”, GoF
“SOA Design Patterns”, Thomas Earl
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.
Organizing Domain Logic
Transaction Script
Table Module
Domain Module
Service Layer
Domain Model
An object model of the domain that incorporates both
behavior and data
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)
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
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
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
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.
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
Data Transfer Object
An object that carries data between processes in
order to reduce the number of method calls
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
Subjects
Plugin
Links classes during configuration rather than
compilation.
Factory
Define an interface for creating an object, but let the
classes that implement the interface decide which class
to instantiate
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.
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.
Questions?
Thank you!
