Please enable JavaScript.

Coggle requires JavaScript to display documents.

DDD (Nackdelar (Målet kan bli att religiöst implementera DDD, istället för…

- - - - Frågor
        
        Är alla entiteter aggregates?
  - - - Terms
        
        Bounded Context - Can be seen as a miniature application containing its own domain, code, and persistence mechanism. Each bounded context should be independent of other bounded contexts.
        The advantages of dividing a large application into smaller bounded contexts helps separate different concerns and makes the application more modular
        Examples of bounded contexts in an e-commerce system:
        
        Inventory
        
        Delivery
        
        Accounts
        
        BBOM - Big Ball of Mud. An application with an unregulated growth.
        
        Persistence Ignorance - You do not need to know how and where the data of your domain will persist. This ignorance about your persistence medium will make your domain model free from any coupling with the persistence layer of the application. This will eventually separate the concerns of the persistence and its communication mechanism from your domain model. In result, your application will be free from coupling with any data store and will be very easily unit testable.
      - Concepts
        
        Identify Concepts
        
        Question1: Can you imagine a window without a room?
        Question2: Does a window have any identity without the room it is residing in?
        Answering these questions will expose the following concepts of DDD.
        Entity.
        Value Object.
        Aggregates & Aggregate root.
        
        Types
        
        Value Object - Does not have a unique identity. It represents something by its values only. A Value Object should probably be immutable.
        Examples:
        
        Window in the room
        
        Address of a person on your website.
        
        A SearchCriteria for your search.
        
        Aggregate & Aggregate Roots
        Scenarios:
        
        A window can only be defined if there is a room.
        
        An order note can only exist if an order is placed.
        
        A question detail can only be there if a question is asked.
        
        In the examples given above; room, order, and question are aggregate roots. On the other hand window, order note and question detail are our aggregates. Aggregates are only accessed through the aggregate root.
        
        A question detail should in no way be saved unless the corresponding question is saved.
        
        A question detail should in no way be retrieved unless the corresponding question is retrieved.
        
        Repository (Design Pattern) - Mediates between the domain and data mapping using a collection-like interface for accessing domain objects. It is more like a facade to your data store that pretends to be like a collection of your domain. Note that repository doesn’t talk in terms of “data”, it talks in terms of Aggregate Roots.
        
        Service - A way of dealing with actions, operations, and activities. Logic should usually be in the Entities but sometimes when we deal with complex operations or need to expose the actions of the aggregate roots to the rest of the world, it's good to have a domain service to act as a facade layer of the business logic and operations of your domain.
        
        Entity - “This is my Entity, there are many like it, but this one is mine.”
        The key defining characteristic of an Entity is that it has an Identity – it is unique within the system, and no other Entity, no matter how similar, is the same Entity unless it has the same Identity.
        
        Examples:
        
        Your bedroom in an apartment
        
        An article on CodeProject
        
        A contract on Facebook
      - Frågor
        
        Kan Value Objects innehålla Entities?
        
        Är domain, context och bounded context samma sak?
        
        Är alla Entities aggregate roots och alla Value Objects aggregates?
        
        Hur implementerar man Repository Pattern enligt DDD?
        
        Vad för typ av logik ska finnas i Entities respektive Services?
    - - What is DDD
        
        It aims to ease the creation of complex applications by connecting the related pieces of the software into an ever-evolving model.
        
        Core Principles
        
        Focus on the core domain and domain logic
        
        Base complex designs on models of the domain
        
        Constantly collaborate with domain experts, in order to improve the application model and resolve any emerging domain-related issues
        
        Terms - from Evans' Domain-Driven Design book
        
        Context - the setting in which a word or statement appears that determines its meaning. Statements about a model can only be understood in a context.
        
        Model - A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.
        
        Ubiquitous Language - A language structured around the domain model and used by all team members to connect all the activities of the team with the software.
        
        Bounded Context - A description of a boundary (typically a subsystem, or the work of a specific team) within which a particular model is defined and applicable.
        
        Building Blocks - high-level concepts that can be used in conjunction with one another to create and modify domain models
        
        Value Object - An immutable object that has attributes. but no distinct identity
        
        Entity - An object that is identified by its consistent thread of continuity, as opposed to traditional objects, which are defined by their attributes. The domain expert will refer to it as a single, identifiable item like Customer, Invoice, Order, Article.
        
        Domain Event - An object that is used to record a discrete event related to model activity within the system. While all events within the system could be tracked, a domain event is only created for event types which the domain expert cares about.
        
        Aggregate - A cluster of entities and value objects.Rather than allowing every single entity or value object to perform all actions on its own, the collective aggregate of items is assigned a singular aggregate root item.
        
        Service - An operation or form of business logic that doesn't naturally fit within the realm of objects. If it can't be related to an entity or value object, it's probably a service.
        
        Repositories - A service that uses a global interface to provide access to all entities and value objects within a particular aggregate collection. Removes data query capabilities from within the business logic of object models.
        
        Factories - DDD suggest the use of a factory to encapsulate the logic of creating complex objects and aggregates, ensuring that the client has no knowledge of the inner-workings of object manipulation.
      - Frågor
        
        Vad är aggregater, egentligen?
        
        När vet man om det ska vara en entity eller value object?
        
        Hur ser ett Repository ut, och vem använder repository't?
  - - - Create a custom type?
        
        If you ask this, then you should probably do it
        
        It's hard to add a custom type at a late stage. It's easy to remove a type you ended up not needing.
  - - - Primitive Obsession
        
        Create more classes, more types to bring meaning to the domain model we have
      - Factory Method
        
        Immutability
        
        Easier to change the code at a later state
        
        You can have validation
        
        Good if you have 3 parameters. If more, maybe a builder is better
      - Value Object should implemet equals
        
        Their identity is based on their state rather than on their object identity. This way, you can have multiple copies of the same conceptual value object. (Remember to also implement HashCode)
      - Add your logic to your Entities if possible. If it doesn't make sense, maybe a service is the way to go
    - - Service
        
        A verb of importance, like "transfer" in a banking system
        
        Tend to be stateless
      - A repository for every Aggregate Root (Entity)
      - Example
        
        Source Code
        
        Example Video
      - Recommended Resources
  - - - Resource
        
        Domain-Driven Design Fundamentals by Julie Lerman and Steve Smith (available at Pluralsight)
        
        http://dddcommunity.org/
        
        http://domainlanguage.com/