• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Taming Complex Domains with Domain Driven Design
 

Taming Complex Domains with Domain Driven Design

on

  • 5,346 views

My short presentation about Domain Driven Design, focusing on the Strategic View of the system.

My short presentation about Domain Driven Design, focusing on the Strategic View of the system.

Statistics

Views

Total Views
5,346
Views on SlideShare
5,343
Embed Views
3

Actions

Likes
10
Downloads
278
Comments
0

2 Embeds 3

http://www.lmodules.com 2
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Taming Complex Domains with Domain Driven Design Taming Complex Domains with Domain Driven Design Document Transcript

    • Taming complex domains with Domain Driven Design Copyright
Alberto
Brandolini
2008
    • About me 10 years experience in IT, mainly as a consultant Took part in many large scale projects Government(s) Banking Insurances A foot in the process, the other in the architecture. Seasoned trainer My blog: http://ziobrando.blogspot.com My e-mail: alberto.brandolini@gmail.com Copyright
Alberto
Brandolini
2008
    • What are we talking about? The DDD book, by Eric Evans has been published in 2004, gaining increasing momentum since then. Copyright
Alberto
Brandolini
2008
    • ...from the source Domain-driven design is not a technology or a methodology. It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains. Copyright
Alberto
Brandolini
2008
    • DDD - what it is and why it matters W i Copyright
Alberto
Brandolini
2008 This is an approach that goes from small to large scale.
    • DDD - what it is and why it matters W It’s a set of proven modeling techniques i especially targeted to complex applications. Copyright
Alberto
Brandolini
2008 This is an approach that goes from small to large scale.
    • DDD - what it is and why it matters W It’s a set of proven modeling techniques i especially targeted to complex applications. It’s a set of principles and practices supporting the development process. Copyright
Alberto
Brandolini
2008 This is an approach that goes from small to large scale.
    • DDD - what it is and why it matters W It’s a set of proven modeling techniques i especially targeted to complex applications. It’s a set of principles and practices supporting the development process. It’s a set of patterns that support a clean and coherent view of the domain model. Copyright
Alberto
Brandolini
2008 This is an approach that goes from small to large scale.
    • DDD - what it is and why it matters W It’s a set of proven modeling techniques i especially targeted to complex applications. It’s a set of principles and practices supporting the development process. It’s a set of patterns that support a clean and coherent view of the domain model. It’s a set of pragmatic strategies allowing applications to scale in size and complexity maintaining their integrity. Copyright
Alberto
Brandolini
2008 This is an approach that goes from small to large scale.
    • DDD - what it is and why it matters W It’s a set of proven modeling techniques i especially targeted to complex applications. It’s a set of principles and practices supporting the development process. It’s a set of patterns that support a clean and coherent view of the domain model. It’s a set of pragmatic strategies allowing applications to scale in size and complexity maintaining their integrity. Copyright
Alberto
Brandolini
2008 This is an approach that goes from small to large scale.
    • Design pattern book? Wasn’t OOP enough? OOP original value proposition has been enhanced in many directions primarily addressing architecture and design issues. Still, OOP falls short and lacks well established disciplines to model complex domains. In the past, tools and frameworks have twisted the original OO paradigm silently constraining domain modeling techniques Copyright
Alberto
Brandolini
2008 The original OOP hype was centered on the myth of reuse. Really reusable solutions appeared in the form of patterns (Design patterns, GRASP patterns, Architectural patterns and so on). They primarily focused on design and architecture, also because they were domain-neutral and allowed for potentially higher reusability. The only notable effort to fill this gap is Martin Fowler’s book Analysis Patterns.
    • The premise The primary focus should be on domain and domain logic Complex domain design should be based on a model Copyright
Alberto
Brandolini
2008 Technology, per se, does not provide a key competitive advantage in building a competitive software.
    • The ecosystem Agile Software Development practices should be in place, allowing short iterations to gather users’ feedback from users and domain experts. Copyright
Alberto
Brandolini
2008
    • The Model
    • Copyright
Alberto
Brandolini
2008
    • Copyright
Alberto
Brandolini
2008
    • Copyright
Alberto
Brandolini
2008
    • Why do we need a model? A model is a representation of the domain serving a specific purpose. There is no “perfect” model for a given domain. A good model is tailored on the given purpose. Copyright
Alberto
Brandolini
2008
    • Expressing the model Model and the underlying design must evolve in sync. Model Code is the ultimate way to express the model. Design Intermediate artifacts, diagrams and docs serve a temporary goal. Copyright
Alberto
Brandolini
2008
    • Lo-fi UML Many tools twisted the purpose of UML, focusing on code generation capabilities, reverse engineering, color gradients and so on. but Modeling activity is too crucial to be performed in isolation. Heavyweight UML might prevent domain experts from contributing to the model. Use a valuable subset of UML to communicate effectively with the team and domain experts. Copyright
Alberto
Brandolini
2008 One notable exception is the old TogetherJ, whose roundtrip features might help to keep diagrams and code in-sync. But problems related to isolation and shutting down the communication channel with the domain expert were still open.
    • The Mindset Copyright
Alberto
Brandolini
2008
    • Continuous Learning Learning about the underlying domain is often considered a byproduct or a side-effect. Many projects sponsor learning new technologies or architectures, but rarely consider the domain among the valuable topics. Continuous learning, instead, is a key activity for a successful project, and is the only way to deliver a useful model Copyright
Alberto
Brandolini
2008
    • Working with domain experts Team and domain experts continuously refine their model and their understanding of the domain. Communication channel between the domain expert and the team must be kept open. Copyright
Alberto
Brandolini
2008
    • Knowledge crunching Our job is to be able to translate any domain into the most useful model. To achieve this goal we must crunch the amount of knowledge available from domain experts, users, books... Copyright
Alberto
Brandolini
2008
    • Ubiquitous language Knowledge about the domain is expressed in a ubiquitous language, allowing domain experts, designers, testers, and developers to share and maintain the same vision. Terms of the ubiquitous language must be unambiguous and agreed by all parties. Copyright
Alberto
Brandolini
2008
    • The Breakthrough • Learning does not happen brick by brick • Learning is not a linear process • A deeper level of knowledge implies refactoring of the existing solution Copyright
Alberto
Brandolini
2008 This is a key moment in DDD. When we recognize that our understanding of the domain has improved also the code must follow. This is tricky and hard to achieve. An exploratory session backed up by tests is often the best solution.
    • Refactoring the Domain Our knowledge of the Domain is challenged by Continuous Learning. The more we learn, the more the existing model must be evolved accordingly. Brainstorming and Refactoring help experimenting new versions of the domain model. Availability of an automated test suite greatly enhances our domain refactoring capabilities. Copyright
Alberto
Brandolini
2008 Our vision of the domain and our implementation must be strictly tied. Consciously leaving a gap between the ideal implementation and the real one complicates domain management providing little value. This is an argument that an be vigorously opposed by project managers, if they’re thinking short-term. The main weapons to make this option viable are: • having the implementation as close as possible to our understanding of the model (gaps build on gaps) • having a test suite in place, targeted against our domain objects. • Experiment. Assumptions are generally negative: estimations of refactoring tasks are often larger than necessary. Ripple effects are valuable knowledge
    • Implementing a model: DDD Building Blocks
    • Building our model Regardless of the domain complexity, an application domain might be represented with specific classes, assuming specific roles and partitioning the domain model in well structured regions Copyright
Alberto
Brandolini
2008
    • Building blocks On a small scale, every domain exposes a peculiar but repeatable structure, organized in families of classes with specific purposes. Entities Value Objects Services Modules Aggregates Factories Repositories Aggregate Objects Domain Events Copyright
Alberto
Brandolini
2008
    • Entities • Objects with an identity and a state. • Generally with a counterpart on persistent storage support. • Their state evolves as long as the application lives Copyright
Alberto
Brandolini
2008
    • Value Objects Have no conceptual identity. Can be designed as immutable Can be shared between different entities Copyright
Alberto
Brandolini
2008
    • Services A service represent an operation which is peculiar to the domain model The interface is defined in term of other elements of the domain model The operation is stateless Domain specific services belongs to the Domain layer Copyright
Alberto
Brandolini
2008
    • Modules Modules are a way to partition the system to make it more manageable Many languages implement them as packages In DDD, packages should be divided according to the purpose instead of the object type. Object type should result evident by the Naming Convention Copyright
Alberto
Brandolini
2008
    • Aggregates A cluster of associated objects that we treat as a unit for he purpose of data changes. Guarantees integrity of the enclosed Entities and Value Object A specific entity is selected as a root of the aggregate Copyright
Alberto
Brandolini
2008
    • Aggregate Root contours Aggregate roots and entities partition the domain into non overlapping <<Aggregate Root>> <<Entity>> regions. A B Access to entities <<Entity>> C <<Aggregate Root>> <<Entity>> might only be D F performed through the corresponding <<Entity>> E <<Entity>> G root. Copyright
Alberto
Brandolini
2008 Interestingly, this works pretty well to solve intricated double update problems or to define lazy loading strategies, and so on.
    • Factories Correct creation of an instance of a complex object does not belong to the object itself. Specific objects have the responsibility of creating the requested object instances Copyright
Alberto
Brandolini
2008
    • Repositories Repositories provide data retrieval capabilities to the domain model providing the illusion of an in-memory collection. They abstract interaction with the underlying persistence layer offering services in terms of domain model elements Copyright
Alberto
Brandolini
2008
    • Aggregate Object Sometimes the responsibilty of the whole aggregate doesn’t really belong to the Aggregate Root entity. Sometimes preserving integrity of the aggregate as a whole is a responsibility that deserves a role of its own An Aggregate Object might coordinate invariants checking and state management between the different entities of the aggregate Copyright
Alberto
Brandolini
2008
    • Domain Event Sometimes our application is just tracking things that happen. Those are normally modeled as Value Objects, but there’s no point in sharing, cause those events are intrinsically unique. a Domain Event represents an event which is meaningful in the domain. Copyright
Alberto
Brandolini
2008 There’s a similar concept in UML in Colour, which is called Moment-interval.
    • Putting it all together... Taken one by one, the patterns are not a revolution. These patterns have been collected from successful project, not invented. Yet, taken together, they provide a scalable approach to manage complicated domains. Copyright
Alberto
Brandolini
2008
    • Renewing building blocks DDD is a technology-neutral paradigm, but since the original enunciation the technical landscape evolved. Copyright
Alberto
Brandolini
2008 Some problems are no longer open, or the DDD solution suggested in the book
    • The good news Many of the original shortcomings of mainstream architecture blueprints have recently downsized. POJO based frameworks, ORM frameworks might offer a mainstream solution to some of the most common issues. Copyright
Alberto
Brandolini
2008 Some problems are no longer open, or the DDD solution suggested in the book
    • Don’t fight your frameworks DDD is a set of principles, rather than a reference implementation. Choose the solution that fits best your development scenario, but keep track of the trade-off cost Copyright
Alberto
Brandolini
2008 Some problems are no longer open, or the DDD solution suggested in the book might look obsolete nowadays. Factories are often managed by Spring or Hibernate
    • Strategic Domain Driven Design
    • Increased project size introduces new challenges to project management, architecture and domain modeling as well Copyright
Alberto
Brandolini
2008
    • In a software development project, different finite resources have to be managed and wisely allocated, to deliver the highest possible value. This applies to time and budget, but also to skills, talent, knowledge and expertise Copyright
Alberto
Brandolini
2008
    • Different domains are subjected to different forces resulting in different speeds and directions of the evolutions Copyright
Alberto
Brandolini
2008
    • Interlude: Biased history of a language Copyright
Alberto
Brandolini
2008
    • Many sources influenced the original model Copyright
Alberto
Brandolini
2008 ... and the Romans were amongst then
    • reference implementations helped to establish a standard Copyright
Alberto
Brandolini
2008
    • Large scale adoption of a standard bred variations Copyright
Alberto
Brandolini
2008
    • A subset of the domain became a lingua franca allowing interoperability between different systems Copyright
Alberto
Brandolini
2008 They were not originally meant to be part of the system
    • Despite all the efforts to produce extensive documentation, single domains still evolve Copyright
Alberto
Brandolini
2008
    • Some domains do not adhere to standards Copyright
Alberto
Brandolini
2008
    • Some domains do not adhere to standards Copyright
Alberto
Brandolini
2008
    • Some ... and domains probably do not never adhere will to standards Copyright
Alberto
Brandolini
2008
    • Still, new requirements and media might introduce changes also in consolidated domains Copyright
Alberto
Brandolini
2008
    • Large-scale DDD Copyright
Alberto
Brandolini
2008
    • Size matters larger or more complicated domains cannot be managed in the same way: - purposes start to diverge - communication is less effective as team size increases - efforts to maintain a coherent view might outweigh its benefits Copyright
Alberto
Brandolini
2008
    • Partitioning - Larger domains can be partitioned in order to maintain a coherent view, in a bounded context. - The overall view must still be shared, as well as some key artifacts - Splitting areas provides a more efficient way to evolve in a coherent context. - Partitioning isn’t meant to be necessarily a phisical action. Sometimes it’s just accepting reality. Copyright
Alberto
Brandolini
2008
    • Context map Model in context Translation Map Model in context A model is valid in a specific context. Different context might need different version of the model, due to specific purposes Copyright
Alberto
Brandolini
2008 So, we need a way to define contours and boundaries at a conceptual level. This will help us to have a snapshot of the exact shape of the system.
    • Shaping subdomains Models must preserve their integrity. A well defined domain can be defined by a well defined team serving a specific goal. Copyright
Alberto
Brandolini
2008 A context is an environment (team, project, subproject) where a model can have its own integrity.
    • Prioritizing subdomains Areas that provide the most significant value to the application must be highlighted and isolated from the surroundings Copyright
Alberto
Brandolini
2008 It takes significant skills and energy to build a good model. We can’t apply them equally in the large. We must find the sweet spot and focus where it matters more.
    • Core Domain The portion of the application that provides the most value to the enterprise. Focus on this portion of the system to provide the most significant value. Preserve the domain from external influences Copyright
Alberto
Brandolini
2008
    • Generic Subdomain A portion of the system which is not delivering specific value. Sub optimal or tactical solutions are viable opportunities: build, outsource, buy, reuse. Copyright
Alberto
Brandolini
2008 This portion of the application is needed, but making it perfect would not provide an signigicant increase in the value. The driver to determine value is always the business, so keep aligne with the business drivers for your domain.
    • Shared Kernel Shared Kernel Model in context Model in context Translation Map An agreed subset of the system might be shared between different teams. Strict coordination rules apply Copyright
Alberto
Brandolini
2008 Some portions of your application might be shared. Different teams might need to coordinate evolution of a shared portion of the system. However, coordination is expensive and it’s not always applicable.
    • Customer Supplier Establish a customer-supplier relationship between the teams. Development processes and planning will be correlated. Share a translation map between the teams Copyright
Alberto
Brandolini
2008 There’s a formal agreement in place, meaning that both team have to agree on some practices and relationship between the two. This clearly has a cost, which has to be evaluated, within the organization.
    • Conformist Passively adapt to another team’s model. Implement a non-optimal solution in a subdomain, to decrease communication costs between the team Copyright
Alberto
Brandolini
2008 If the Customer Supplier does not work... the battle could just be not worth the fight. This is a cheaper option from the organization’s point of view, but will also provide less value to the application.
    • Anticorruption Layer A defense mechanism might be necessary to prevent leaking from one domain to another one. Integrating different domains does not mean that they serve the same purpose. An anti-corruption layer isolates the translation and adaptation role in a specific layer Copyright
Alberto
Brandolini
2008 In some cases the borderline between two contexts needs to be guarded, to prevent concepts to leak in outside their boundaries. The same concepts might have different representations in the two contexts. The ACL is where the translation happens, even in a “dirty way”.
    • Open Host Sometimes, we know only one side of the boundary. Integration might happen with an undefined number of external context. We are not free anymore to define ad-hoc policies: an Open Host defines this type of relationship Copyright
Alberto
Brandolini
2008 This is a fairly common situation in a SOA context. It can easily be tracked down to the English language example, meaning that once shared (as it is in Europe) a model isn’t free to evolve, because it turns into an integration level artifact.
    • Published Language Opening a door to multiple context means giving up the freedom to evolve the underlying model. Sometimes, the language spoken at the border becomes a model on its own. Sometimes, a standard language already exists on a given domain, increasing integration possibilities. Copyright
Alberto
Brandolini
2008 SOA again gives us some examples: you can create a web service in seconds, exposing your domain objects. But once published you’re sometimes givin’up the possibility to evolve. A service exposed to an open channel/bus means that there is anothe model, living on the channel.
    • Separate ways Sometimes, the cost of integration is higher than the integration benefits. Short term, quick or simply unrelated solution does not necessarily belong to the big plan Do we really need to integrate them anyway? Copyright
Alberto
Brandolini
2008
    • References Domain Driven Design Eric Evans Addison Wesley Copyright
Alberto
Brandolini
2008
    • References Apply Domain Driven Design and Patterns Jimmy Nilsson Addison Wesley Copyright
Alberto
Brandolini
2008
    • Domain Driven Design discussion groups • http://tech.groups.yahoo.com/group/ domaindrivendesign/ • http://it.groups.yahoo.com/group/DDD-IT/ Copyright
Alberto
Brandolini
2008
    • Questions? Copyright
Alberto
Brandolini
2008