The Internet belongs to everyone. Let’s keep it that way.

Protect Net Neutrality
Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Evaluating Domain-Driven Design

No description
by

Hayato Hess

on 26 November 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Evaluating Domain-Driven Design

Evaluating Domain-Driven Design
for Refactoring Existing Information Systems

Final Master Thesis Presentation at Ulm University
Institute of Database and Information Systems
Hayato Hess | May 18, 2016
Agenda
Introduction
Challenges
Evaluating DDD for Refactoring Existing Information Systems | May 05, 2016
Herbert Hayato Hess
Computer Science Student at Ulm University
Submitted Master Thesis

Dr. Jan Scheible
MERCAREON's Employee
Master Thesis Advisor

Spin-Off of TRANSPOREON (Logistic software company)
Located in Ulm and Kraków
28 Employees
Main Product: Time Slot Management System
MERCAREON
Mercareon
< 2009 TP Frok
2009 MERCAREON
2016 GXT
2011-2015 C# to JAVA
Long Time Maintenance
Maintenance Challenges
Domain-Driven
Design

Language shared by all involved parties
Improves communication and prevents misunderstandings
Ubiquitous Language
Bounded Contexts
Ubiquitous Language Boundary
Code, Database, Team Distribution Boundary
Value Objects
Defined by its attributes
Immutable
When an attribute is changed, a new value object is instantiated
Entity
Defined by its identity
Unique beyond the life cycle of the system
Aggregate
One root entity
Multiple entities
Multiple value objects
Consistency boundary
Transactions
Concurrency
Services
Challenge
Domain-Driven Design was not designed for architectural refactoring
How to derive entities, value objects, aggregates, object methods and services?
Solution: Model Transformations
Architecture
Prototype
Thank You For Your Attention!
Refactoring
Artifact - Model Transformation:
Ubiquitous Language
Buisiness Operations
Provide access to aggregates
Wraps data sources such as databases
Implementation can be replaced for testing
Repositories
Long time maintenance
Add new features
Improve existing features

Aggregate Transformation
Organize related concepts and tasks
Reduce complexity
Increase Cohesion
Decrease Coupling
Modules
Aggregate Model
Service Model
Source Model
Refactoring Realization
Bubble Context for the Liveyard View
Communication With The Legacy System by utilizing Ports and Adapters
Introduction
Challenges
Domain-Driven Design
Refactoring
Prototype
> Source Model
Model - Artifact Transformations:
Final Model > Visualizations
Model - Model Transformations:
Source Model > Final Model
Time Slot Management System
Application Services
Offer operations supported by the bounded context
Can access repositories
Controls the transactions & safety
In charge of event based messaging

Domain Services
Contains domain knowledge
Encapsulates business logic that doesn't naturally fit within a domain object
DDD based System
Existing System
Resulting Artifacts
Source: Martin Fowler.
Patterns of enterprise application architecture.
TR
TR
1
10
2
5
Excerpt of a Transformation Rule (TR):
Full transcript