O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Domain driven design

Próximos SlideShares
Domain Driven Design
Domain Driven Design
Carregando em…3

Confira estes a seguir

1 de 18 Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Semelhante a Domain driven design (20)


Mais recentes (20)

Domain driven design

  2. 2. Agenda Why Building blocks ◦ Repositories, entities, specifications etc. Putting it to practice ◦ Dependency injection ◦ Persistence ◦ Validation ◦ Architecture Challenges When not to use DDD
  3. 3. Software is complicated
  4. 4. Traditional Architecture
  5. 5. Onion Architecture -Domain model != view model (The M in MVC) -Instead of depending downwards, dependencies goes inwards
  6. 6. public bool CanBook(Cargo cargo, Voyage voyage) { if (!overbookingPolicy.IsAllowed(cargo, voyage)) return false; ... } public bool CanBook(Cargo cargo, Voyage voyage) { double maxBooking = voyage.Capacity * 1.1; if (voyage.BookedCargoSize + cargo.Size > maxBooking) return false; ... }
  7. 7. Domain Model
  8. 8. The domain model requirements and phases
  9. 9. Solution Structure
  10. 10. Essentials of DDD - Entities -Like a person, you can change everything about them: name, address, sex -But over their whole lifetime they’re still the same person -Same with object, entities are the same object for the duration of their lifetime -Implemented with an identifier or ID
  11. 11. Essentials of DDD – Value Objects Value Objects -Value types on the other hand -Are identified by their value -E.g. color, addresses, shopping lists - Define by logic and data - Any two value objects with same data are the same - They are immutable
  12. 12. Essentials of DDD – Aggregates Value Objects -Cluster of objects -Consistency boundary -Simplifies things massively -Master object called aggregate root
  13. 13. Essentials of DDD – Aggregate Root Value Objects -Cannot hold reference to anything except the root -Can’t access any entity except from the root -Consistency boundary -Save the whole thing -Cascades -Versioning -Locking – coarse grain lock
  14. 14. Essentials of DDD – Repository Value Objects -Common pattern -When you need something -Where you put things when your application isn’t using them - Abstracts away persistence - One repository is specific to one type of aggregate root - It contains collection of instance of aggregate - And provide operations of loading and saving aggregate instance
  15. 15. Essentials of DDD – Bounded Context Value Objects -Different definitions in different contexts -E.g. different departments may reuse language differently Data Model applies or lives inside Bounded Context In an enterprise with many domain, many Bounded Context exist together Bounded Context refers to different aspect of the domain
  16. 16. Essentials of DDD – Dependency Injection Value Objects -All about interfaces -Decouple our code -Depend on the model, not the implementation -Users of INotificationService have no idea -Instead of calling out -Inversion of control public class LeaveService { private readonly INotificationService notifications; public LeaveService(INotificationService notifications) { this.notifications = notifications; } public void TakeLeave(Employee employee, DateTime start, DateTime end) { this.notifications.Notify(employee, "Leave approved."); } }
  17. 17. Essentials of DDD – Validation Is the first name filled in? Is the e-mail address format valid? Is the first name less than 255 characters long? Is the chosen username available? Is the password strong enough? Is the requested book available, or already out on loan? Is the customer eligible for this policy? public class PersonRepository : IPersonRepository { public void Save(Person customer) { if (!customer.IsValid()) throw new Exception(...) } } Validating only before it writes to the DB - self-validating entities (doesn’t work for different contexts)
  18. 18. When DDD isn’t appropriate  -DDD is for dealing with complex domains  -If you don’t have a complex domain  -If you have no behavior or logic  -If your ’model’ maps perfectly to a relational DB schema  -Clues that you don’t need DDD  -If you don’t have access to a domain expert

Notas do Editor

  • Welcome
    About domain dd
  • Challenge development habits

    constraints -ve
    std approaches, prevents creativity
    comfort zone
    just in case
  • big code, code not in control, dev struggle to keep code afloat

    client replace old system


    UI -WCF-> Server -ORM-> DB

    lots of model transformation going on
    ORM converts data into object mapper, properties convert data into UI datasets

    database driven system
    fat service layer
    non model centric
  • An object that is not defined by its attributes, but rather by a thread of continuity and its identity.
  • An object that contains attributes but has no conceptual identity.
    It is defined by logic and data.
    2 vO with same data are the same
    them immutable

  • If you follow a database-first approach, you aggregate root is usually the table on the 1 side of a 1-many relationship.
    The most common example being a Person. Each person has many addresses, one or more pay slips, invoices, CRM entries, etc.
  • A collection of objects that are bound together by a root entity, otherwise known as an aggregate root.

    The aggregate root guarantees the consistency of changes being made within the aggregate by forbidding
    external objects from holding references to its members.
  • One repository is specific to one type of aggregate root
    contains collection of instance of aggregate
    provide operations of loading and saving aggregate instance
  • DM applies or lives inside BC

    in enterprise with many domain, many BC exist
    BC to refer different aspect of the domain

    Exterme domain model focus