Domain Driven Design
•Download as PPTX, PDF•
11 likes•4,510 views
An introduction to the concepts of domain driven design
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (12)
Similar to Domain Driven Design
Similar to Domain Driven Design (20)
Recently uploaded
Recently uploaded (20)
Domain Driven Design
- 1. Introduction To Domain Driven Design Nader Albert
- 2. References Domain Driven Design Eric Evans
- 3. Agenda Domain Driven Design Definition Problem Definition Key Terms and Concepts Principles and Objectives Domain Driven Design Patterns Domain Model Unification Domain Driven Design in Action Tips and Warnings
- 4. Domain Driven Design Definition
- 6. Fractured Language Project Manager Developer Vaguely understands new domain Struggles to become bilingual and starts to translate Domain Expert Vaguely describes what he wants
- 7. Key Terms and Concepts • • • • • Domain Model Domain Model Domain Context Ubiquitous Language
- 8. Domain Sphere of Knowledge. Subject Area of Interest Domain Model Domain Model Context Ubiquitous Language
- 9. Domain Health Care Domain Domain Model Education Domain Domain Model Context Ubiquitous Language
- 10. Model Represent Behavior in different shape Distillation of knowledge Language Backbone Domain Model Domain Model Context Ubiquitous Language
- 12. Domain Model • Extracts domain essential elements, relevant to a specific use. • Layer of abstractions representing selected aspects of a domain. • Contains concepts of importance and their relationships in a certain domain. • Not concerned with physical data storage or processing. Domain Model Domain Model Context Ubiquitous Language
- 13. Domain Model • May include concepts that are not currently computerized. • Consistent logical model and a shared glossary of terminology. • Starting point for more detailed analysis. • Validates I.T. understanding of the business domain and its concepts. Domain Model Domain Model Context Ubiquitous Language
- 14. Domain Model Ma p Domain Model of t he For e s t Domain Model Context Ubiquitous Language
- 15. Domain Context The setting in which a word or a statement appears with a specific meaning. Domain Model Domain Model Context Ubiquitous Language
- 21. Principles Ubiquitous Language used in all project aspects Domain Model Drives Design. discipline Speak a Ubiquitous Language within a bounded context understanding Domain Model is a Backbone of a Domain Language Focus on Model of the Domain, rather than Technology
- 22. Objectives Software and Domain practitioners can collaborate. Model Driven Architecture (MDA) can be applied. A Domain Specific Language (DSL) can be formulated. Robust application
- 23. Domain Driven Design Patterns Defined Application Layers Defined Application Models Defined Application Contexts
- 24. Domain Driven Design Patterns Defined Application Layers
- 25. Layered Architecture Layered Application Architecture
- 26. Layered Architecture Concentrate domain code in one layer, isolated from user interface, application, and infrastructure code. Clean separation of concerns keeps the design of each layer easy to understand, maintain and extend. Domain objects (models and services) becomes focused on expressing the business domain.
- 27. Layered Architecture Online Banking use case
- 28. Domain Driven Design Patterns Defined Application Models
- 29. Entity Model Distinguished by its identity rather than its attributes. Identity maintained immutable across all forms (formats) of an object. Equal attribute values doesn’t indicate Identical objects. Non equal attribute values doesn’t indicate Non Identical objects.
- 30. Entity Model Java Runtime Domain Every object instance is an Entity. Identity is the object location in memory. Banking Domain Two deposits of the same amount to the same account on the same day, triggered by the same person are two Separate Deposit Operations. Identity is an auto-generated key, guaranteed to be unique.
- 31. Entity Model Same real-world thing might / might not be represented as an entity in a domain model Identity might / might not be of interest to the application user
- 32. Value Model Describes the characteristics of a thing. Represents a descriptive aspect of the domain with no conceptual identity. Two markers of the same color and same shape are the same markers.
- 33. Value Model Same thing can sometimes be considered as Value object and some other times as Entity object. Retailer Application Money Printer Application
- 34. Value Model Address model is a Value object or an Entity Object? Value Postal Service Application Entity Electrical Utility Application
- 35. Value Model Value objects can reference Entity objects
- 36. Value Model A person is an Entity and its name is a Value. Value objects are interchangeable. Value objects are immutable (name shouldn’t change in every person) Usually found by traversal from some entity. Finding a Value with specific properties = Creating a new instance with the same properties.
- 37. Service Model Refer to an activity (verb) rather than an entity (noun). Services are stateless. Banking Domain Services Transfer Balance From one Account to another Account Export Balance to Excel Send Email
- 38. Aggregate Model A cluster of associated objects treated as a unit for the purpose of data change. Has a root (Entity) and a boundary (defines what is inside). Root entity has a global identity. Non-Root entities have local identity.
- 39. Aggregate Model Nothing outside the aggregate boundary can hold a reference to anything inside, except to the root entity. Only aggregate roots can be obtained directly with database queries.(other objects must be found by traversal of associations) Root entity can expose references to the internal entities. Usage is only transient, and references shouldn’t be held. Car Model Objects within an aggregate can hold references to other aggregate roots. A delete operation removes everything within the aggregate boundary at once. (cascade delete).
- 40. Domain Driven Design Patterns Defined Application Contexts
- 41. Domain Bounded Context Different models apply in different contexts. Same entity appears in different contexts with different shapes. Context boundaries are a set of conditions (business functionality - Model shall be strictly consistent within a specific bound. Bounded contexts are not modules. A bounded context can enfold other bounded contexts. Name of a bounded context is part of the Ubiquitous Language. application layer – database).
- 42. Continuous Integration Tackles the problem of model fragmentation: Developers may not fully understand the intent of some object or interaction modeled by someone else. Developers may not realize that a concept is already embodied in another part of the model and they start duplicating concepts and behaviors. Work within a context is frequently merged and made consistent. Applied within a single bounded context.
- 43. Context Map Gives a wider and more global vision. Highlights the points of contacts. Standardizes the communication between different contexts. A coherent Context Map, places all the work into Bounded Contexts, with explicit relationships between all connected models. Translation Map
- 44. Context Map Translations required: Route Specification List of location codes List of Node IDs Itinerary Translator (adapter) can be externalized to a separate entity, falling in the shared area between the two contexts (translation map). A typical two way translator would supply: convertSpec (RouteSpecification) : List<LocationCode>. convertPath (List<nodePath>) : Itinerary Two Bounded Contexts
- 45. Context Map public Itinerary route(RouteSpecification spec) { Booking_TransportNetwork_Translator translator = new Booking_TransportNetwork_Translator(); List constraintLocations = translator.convertConstraints(spec); Way 1 translation List pathNodes = traversalService.findPath(constraintLocations); Itinerary result = translator.convert(pathNodes); Way 2 translation
- 46. Shared Kernel Enfold a subset of the domain decided to be shared between the different contexts. Can not be changed as freely as the bounded contexts. Amendment decisions involve consultations with another team. Shared Kernel Represents the core domain.
- 47. Anti Corruption Layer A way to link two bounded contexts, where one of them is a legacy system. Provides clients with functionality in terms of their own domain model, with little modification to the legacy system. Facade Adapter Translator
- 48. Separate Ways Integration is expensive Integration is not always required Decouple bounded contexts from each others When No sharing of logic is required If No sharing of data is required
- 49. Domain Model Unification Seeing Same Thing Differently Seeing Different Things Similarly
- 50. Seeing same thing differently ◦ Different bounded contexts or use cases may have different perceptions about the same physical entity. ◦ Different perceptions may be complementary or contradictory.
- 51. Seeing same thing differently Complementary perceptions: Common parts Shared kernel Each context extends (inherits/aggregates) the core part and enrich it with his own perception. Parts of a larger whole Common parts Shared kernel Contradictory perceptions: Bounded contexts doesn’t accept each other’s model. Nothing to share in common Agree on not to agree (Separate Ways). Something to share in common Adapt to each other (Context Map).
- 52. Unifying the Model Tire Model (complementary perceptions) Tire Weight Radius Speed Manufacturing date Shelf id Car-Tire Retailer-Tire Wheel ID Buying date Selling date Factory-Tire Machine ID Row material defects count Scheduled QA Date
- 53. Unifying the Model Elephant Model (parts – larger whole) Crude Model Deeper model
- 54. Unifying the Model Elephant Model (the contradictory perceptions) 4 contexts – no integration
- 55. Unifying the Model Elephant Model (the contradictory perceptions) 4 contexts – minimal integration Translations: wall.location = tree.place = Snake.location = rope.tie-down
- 56. Seeing different things similarly Ubiquitous language: Assigning the same name to different models. General language: Same Word with different meanings in different sentences. pool of candidate crosses pool of reference crosses pool of plants
- 57. Domain Driven Design Into Action • • • • • Ubiquitous Language in Action Bounded context in Action Aggregates in Action Values in Action Entities in Action
- 58. Ubiquitous Language in Action Established a Robust communication channel with the business domain experts.
- 59. Bounded Context in Action Analysis Context Execution Context analysis orchestration execution orchestration analysis qmats analysis mats analysis shared kernel execution qmats execution mats execution shared kernel MI Shared Kernel Selection Context selection qmats selection mats selection shared kernel
- 60. Aggregate Models in Action ◦ Advantages: Hide irrelevant details. Self documented. Prevents mistaken access to incorrect entities. ◦ Disadvantages: Increased complexity with data retrievals. Can have a negative impact on memory utilization, If not well designed.
- 61. Value Models in Action Without Value Objects List<String> identifyCandidatePopulation (String gnc, String gny, String brc){ //do the job here ..... return new Vector<String>(); } With Value Objects List<CrossNumber> identifyCandidatePopulation (GenerationCode gnc, GNAYear gny, GNABreedingCode brc){ //do the job here ..... return new Vector<CrossNumber>(); }
- 62. Value Models in Action public abstract class StringValueObject implements Serializable { private String value; public StringValueObject (String value){ public class GenerationCode extends StringValueObject implements Serializable { public GenerationCode (String value) { super(value); if (!this.validate(value)) { throw new IllegalArgumentException(getName() + " syntax invalid "); } // do any extra logic here..... } public String getName(){ this.value = value; } return "generation code"; } public String getValue() { return value; } public boolean validate (String value){ if ( (true == value.isEmpty() ) || (false == value.startsWith("F"))){ return false; public abstract boolean validate (String value); public abstract String getName(); } } return true; }}
- 63. Value Models in Action Encapsulating domain values in well defined Value objects. Advantages: Self documented. Compile time validation Increased Code Robustness Good place for runtime validation logic. Serves the Ubiquitous Language. Disadvantages: Increased complexity (creation time / object relational mapping time). Additional class object and instance objects.
- 64. Entity Models in Action public interface EntityService<T> { public int add(T entityResource) throws BusinessException; public int update(T entityResource) throws BusinessException; public T retrieve(int entityId) throws BusinessException; public int remove(T entityResource) throws BusinessException; public int remove(int entityResourceId) throws BusinessException; }
- 65. Entity Models in Action Encapsulating entities in well defined Entity objects. Advantages: Basic Object Behaviour can be encapsulated and reused. Serves the Ubiquitous Language.
- 66. Tips and warnings Real value comes only with complex business domain. Discipline is key. Deep understanding of the domain business is essential. May introduce additional unnecessary complexity.
- 67. Questions
Editor's Notes
- 1- Domain expert vaguely describe what he wants2- Developers, vaguely understand a domain new to them.3- Few members of the team manage to become bilingual, but they become bottlenecks of information flow, and their translations are inexact.On a project without a common language, developers have to translate for domain experts. Domain experts translate between developers and still other domain experts. Developers even translate for each other. Translation muddles model concepts, which leads to destructive refactoring of code.
- 1- Area of interest (education / healthcare / banking / bio-informatics).2- Sphere of knowledge.3- Subject Area to be tackled .
- 1- Area of interest (education / healthcare / banking / bio-informatics).2- Sphere of knowledge.3- Subject Area to be tackled .
- 1- Represent something into a different shape.2- A distillation of knowledge.3- A backbone of a language expressing a specific domain.4- Representation of a static behavior.
- 1- Represent something into a different shape.2- A distillation of knowledge.3- A backbone of a language expressing a specific domain.4- Representation of a static behavior.
- 1- Vocabularyhas to be continuously refined.2- Domain experts use it in discussions with developers.3- Areas of modelinadequacy quickly discovered. (where model seems wrong to the domain expert).4- Developers and domain experts walk through scenarios, using model objects to deepen each other's understanding and refine concepts as they go
- 1- The vocabulary of that UBIQUITOUS LANGUAGE includes the names of classes and prominent operations2- The LANGUAGE includes terms to discuss rules that have been made explicit in the model3- model relationships.The model-based language should be used among developers to describe not only artifacts in the system, but tasks and functionality. This same model should supply the language for the developers and domain experts to communicate with each other, and for the domain experts to communicate among themselves about requirements, development planning, and features. The more pervasively the language is used, the more smoothly understanding will flow2- Vocabularyhas to be continuously refined.3- Domain experts use it in discussions with developers.4- Areas of modelinadequacy quickly discovered. (where model seems wrong to the domain expert).5- Developers and domain experts walk through scenarios, using model objects to deepen each other's understanding and refine concepts as they go
- 1- The vocabulary of that UBIQUITOUS LANGUAGE includes the names of classes and prominent operations2- The LANGUAGE includes terms to discuss rules that have been made explicit in the modeland model relationships.The model-based language should be used among developers to describe not only artifacts in the system, but tasks and functionality. This same model should supply the language for the developers and domain experts to communicate with each other, and for the domain experts to communicate among themselves about requirements, development planning, and features. The more pervasively the language is used, the more smoothly understanding will flow2- Vocabularyhas to be continuously refined.3- Domain experts use it in discussions with developers.4- Areas of modelinadequacy quickly discovered. (where model seems wrong to the domain expert).5- Developers and domain experts walk through scenarios, using model objects to deepen each other's understanding and refine concepts as they go
- DDD and MDA:While DDD is compatible with MDA, the intent of the two concepts is somewhat different. MDA is concerned more with the means of translating a model into code for different technology platforms than with the practice of defining better domain models.DDD and DSL: DDD does not specifically require the use of a DSL, though it could be used to help define a DSL
- An application for booking seats in a stadium might treat seats and attendees as ENTITIES. In the case of assigned seating, in which each ticket has a seat number on it, the seat is an ENTITY. Its identifier is the seat number, which is unique within the stadium. The seat may have many other attributes, such as its location, whether the view is obstructed, and the price, but only the seat number, or a unique row and position, is used to identify and distinguish seats.On the other hand, if the event is "general admission," meaning that ticket holders sit wherever they find an empty seat, there is no need to distinguish individual seats. Only the total number of seats is important. Although the seat numbers are still engraved on the physical seats, there is no need for the software to track them. In fact, it would be erroneous for the model to associate specific seat numbers with tickets, because there is no such constraint at a general admission event. In such a case, seats are not ENTITIES, and no identifier is needed.When the ID is automatically generated, the user may never need to see it. The ID may be needed only internally, such as in a contact management application that lets the user find records by a person's name. The program needs to be able to distinguish two contacts with exactly the same name in a simple, unambiguous way. The unique, internal IDs let the system do just that. After retrieving the two distinct items, the system will show two separate contacts to the user, but the IDs may not be shown. The user will distinguish them on the basis of their company, their location, and so on.There are cases in which a generated ID is of interest to the user. When I ship a package through a parcel delivery service, I'm given a tracking number, generated by the shipping company's software, which I can use to identify and follow up on my package. When I book airline tickets or reserve a hotel, I'm given confirmation numbers that are unique identifiers for the transaction.
- Comparing the objects' locations in memory,is too fragile for our purposes. In most technologies for persistent storage of objects, every time an object is retrieved from a database, a new instance is created, and so the initial identity is lost. Every time an object is transmitted across a network, a new instance is created on the destination, and once again the identity is lost. The problem can be even worse when multiple versions of the same object exist in the system, such as when updates propagate through a distributed database
- An application for booking seats in a stadium might treat seats and attendees as ENTITIES. In the case of assigned seating, in which each ticket has a seat number on it, the seat is an ENTITY. Its identifier is the seat number, which is unique within the stadium. The seat may have many other attributes, such as its location, whether the view is obstructed, and the price, but only the seat number, or a unique row and position, is used to identify and distinguish seats.On the other hand, if the event is "general admission," meaning that ticket holders sit wherever they find an empty seat, there is no need to distinguish individual seats. Only the total number of seats is important. Although the seat numbers are still engraved on the physical seats, there is no need for the software to track them. In fact, it would be erroneous for the model to associate specific seat numbers with tickets, because there is no such constraint at a general admission event. In such a case, seats are not ENTITIES, and no identifier is needed.When the ID is automatically generated, the user may never need to see it. The ID may be needed only internally, such as in a contact management application that lets the user find records by a person's name. The program needs to be able to distinguish two contacts with exactly the same name in a simple, unambiguous way. The unique, internal IDs let the system do just that. After retrieving the two distinct items, the system will show two separate contacts to the user, but the IDs may not be shown. The user will distinguish them on the basis of their company, their location, and so on.There are cases in which a generated ID is of interest to the user. When I ship a package through a parcel delivery service, I'm given a tracking number, generated by the shipping company's software, which I can use to identify and follow up on my package. When I book airline tickets or reserve a hotel, I'm given confirmation numbers that are unique identifiers for the transaction.
- 3- Is "Address" a VALUE OBJECT? Who's Asking?In software for a mail-order company, an address is needed to confirm the credit card, and to address the parcel. But if a roommate also orders from the same company, it is not important to realize they are in the same location. Address is a VALUE OBJECT.In software for the postal service, intended to organize delivery routes, the country could be formed into a hierarchy of regions, cities, postal zones, and blocks, terminating in individual addresses. These address objects would derive their zip code from their parent in the hierarchy, and if the postal service decided to reassign postal zones, all the addresses within would go along for the ride. Here, Address is an ENTITY.In software for an electric utility company, an address corresponds to a destination for the company's lines and service. If roommates each called to order electrical service, the company would need to realize it. Address is an ENTITY. Alternatively, the model could associate utility service with a "dwelling," an ENTITY with an attribute of address. Then Address would be a VALUE OBJECT4- VALUE OBJECTS can even reference ENTITIES. For example, if I ask an online map service for a scenic driving route from San Francisco to Los Angeles, it might derive a Route object linking L.A. and San Francisco via the Pacific Coast Highway. That Route object would be a VALUE, even though the three objects it references (two cities and a highway) are all ENTITIES.
- 4- VALUE OBJECTS can even reference ENTITIES. For example, if I ask an online map service for a scenic driving route from San Francisco to Los Angeles, it might derive a Route object linking L.A. and San Francisco via the Pacific Coast Highway. That Route object would be a VALUE, even though the three objects it references (two cities and a highway) are all ENTITIES.
- 3- Is "Address" a VALUE OBJECT? Who's Asking?In software for a mail-order company, an address is needed to confirm the credit card, and to address the parcel. But if a roommate also orders from the same company, it is not important to realize they are in the same location. Address is a VALUEOBJECT.In software for the postal service, intended to organize delivery routes, the country could be formed into a hierarchy of regions, cities, postal zones, and blocks, terminating in individual addresses. These address objects would derive their zip code from their parent in the hierarchy, and if the postal service decided to reassign postal zones, all the addresses within would go along for the ride. Here, Address is an ENTITY.In software for an electricutility company, an address corresponds to a destination for the company'slinesandservice. If roommates each called to order electrical service, the company would need to realize it. Address is an ENTITY. Alternatively, the model could associate utility service with a "dwelling," an ENTITY with an attribute of address. Then Address would be a VALUE OBJECT
- VALUE OBJECTS can even reference ENTITIES. For example, if I ask an online map service for a scenic driving route from San Francisco to Los Angeles, it might derive a Route object linking L.A. and San Francisco via the Pacific Coast Highway. That Route object would be a VALUE, even though the three objects it references (two cities and a highway) are all ENTITIES.
- Persistent VALUE OBJECTS are usually found by traversal from some ENTITY that acts as the root of the AGGREGATE that encapsulates them. In fact, a global search access to a VALUE is often meaningless, because finding a VALUE by its properties would be equivalent to creating a new instance with those properties. There are exceptions, though. For example, when I am planning travel online, I sometimes save a few prospective itineraries and return later to select one to book. Those itineraries are VALUES (if there were two made up of the same flights, I would not care which was which), but they have been associated with my user name and retrieved for me intact. Another case would be an "enumeration," when a type has a strictly limited, predetermined set of possible values. Global access to VALUE OBJECTS is much less common than for ENTITIES, though, and if you find you need to search the database for a preexisting VALUE, it is worth considering the possibility that you've really got an ENTITY whose identity you haven't recognized.
- Domain ServicesOperations names comes from the Ubiquitous Language (business domain).Parameters and Results comes from the Domain Objects.Operation relates to a domain concept.ex: TransferBalance From one Account to another Account Application ServicesOperations names comes from the Application Specific Requirements (application domain).Parameters and Results may comefrom the Domain Objects.Operation relates to an application feature.ex:ExportBalance toexcelInfrastructure / Utility ServicesOperations names must not come from the Ubiquitous Language.ex:SendEmailSome concepts from the domain aren't natural to model as objects. Forcing the required domain functionality to be the responsibility of an ENTITY or VALUE either distorts the definition of a model-based object or adds meaningless artificial objects.When we force an operation into an object that doesn't fit the object's definition, the object loses its conceptual clarity and becomes hard to understand and re-factor.These "doers" end up with names ending in "Manager“. They have no state of their own nor any meaning in the domain beyond the operation they host. The name service emphasizes the relationship with other objects. Unlike ENTITIES and VALUE OBJECTS, it is defined purely in terms of what it can do for a client. A SERVICE should still have a defined responsibility, and that responsibility and the interface fulfilling it should be defined as part of the domain model. Operation names should come from the UBIQUITOUS LANGUAGE or be introduced into it. Parameters and results should be domain objects.When a significant process or transformation in the domain is not a natural responsibility of an ENTITY or VALUE OBJECT, add an operation to the model as a standalone interface declared as a SERVICE. Define the interface in terms of the language of the model and make sure the operation name is part of the UBIQUITOUS LANGUAGE. Make the SERVICE stateless.Distinguish SERVICES that belong to the domain layer from those of other layers, and to factor responsibilities to keep that distinction sharp.Most SERVICES discussed in the literature are purely technical and belong in the infrastructure layer. Domain and application SERVICES collaborate with these infrastructure SERVICES. For example, a bank might have an application that sends an e-mail to a customer when an account balance falls below a specific threshold. The interface that encapsulates the e-mail system, and perhaps alternate means of notification, is a SERVICE in the infrastructure layer.It can be harder to distinguish application SERVICES from domain SERVICES. The application layer is responsible for ordering the notification. The domain layer is responsible for determining if a threshold was met—though this task probably does not call for a SERVICE, because it would fit the responsibility of an "account" object. That banking application could be responsible for funds transfers. If a SERVICE were devised to make appropriate debits and credits for a funds transfer, that capability would belong in the domain layer. Funds transfer has a meaning in the banking domain language, and it involves fundamental business logic. Technical SERVICES should lack any business meaning at all.
- An AGGREGATE is a cluster of associated objects that we treat as a unit for the purpose of data changes. Each AGGREGATE has a root and a boundary. The boundary defines what is inside the AGGREGATE. The root is a single, specificENTITY contained in the AGGREGATE. The root is the onlymember of the AGGREGATE that outsideobjects are allowed to hold references to, although objects within the boundary may holdreferences to each other. ENTITIES other than the root have local identity, but that identity needs to be distinguishableonly within the AGGREGATE, because no outside object can ever see it out of the context of the root ENTITY.A model of a car might be used in software for an auto repair shop. The car is an ENTITY with global identity: we want to distinguish that car from all other cars in the world, even very similar ones. We can use the vehicle identification number for this, a unique identifier assigned to each new car. We might want to track the rotation history of the tires through the four wheel positions. We might want to know the mileage and tread wear of each tire. To know which tire is which, the tires must be identified ENTITIES also. But it is very unlikely that we care about the identity of those tires outside of the context of that particular car. If we replace the tires and send the old ones to a recycling plant, either our software will no longer track them at all, or they will become anonymous members of a heap of tires. No one will care about their rotation histories. More to the point, even while they are attached to the car, no one will try to query the system to find a particular tire and then see which car it is on. They will query the database to find a car and then ask it for a transient reference to the tires. Therefore, the car is the root ENTITY of the AGGREGATE whose boundary encloses the tires also. On the other hand, engine blocks have serial numbers engraved on them and are sometimes tracked independently of the car. In some applications, the engine might be the root of its own AGGREGATE.
- Now, to translate that conceptual AGGREGATE into the implementation, we need a set of rules to apply to all transactions.1- The root ENTITY has global identity and is ultimately responsible for checking invariants.Root ENTITIES have global identity. ENTITIES inside the boundary have local identity, unique only within the AGGREGATE.2- Nothing outside the AGGREGATE boundary can hold a reference to anything inside, except to the root ENTITY. The root ENTITY can hand references to the internal ENTITIES to other objects, but those objects can use them only transiently, and they may not hold on to the reference. 3- The root may hand a copy of a VALUE OBJECT to another object, and it doesn't matter what happens to it, because it's just a VALUE and no longer will have any association with the AGGREGATE.As a corollary to the previous rule, only AGGREGATE roots can be obtained directly with database queries. All other objects must be found by traversal of associations.4- Objects within the AGGREGATE can hold references to other AGGREGATE roots.5- A delete operation must remove everything within the AGGREGATE boundary at once. (With garbage collection, this is easy. Because there are no outside references to anything but the root, delete the root and everything else will be collected.)6- When a change to any object within the AGGREGATE boundary is committed, all invariants of the whole AGGREGATE must be satisfied.Cluster the ENTITIES and VALUE OBJECTS into AGGREGATES and define boundaries around each. Choose one ENTITY to be the root of each AGGREGATE, and control all access to the objects inside the boundary through the root. Allow external objects to hold references to the root only. Transient references to internal members can be passed out for use within a single operation only. Because the root controls access, it cannot be blindsided by changes to the internals. This arrangement makes it practical to enforce all invariants for objects in the AGGREGATE and for the AGGREGATE as a whole in any state change
- Create an isolating layer to provide clients with functionality in terms of their own domain model. The layer talks to the other system through its existing interface, requiring little or no modification to the other system. Internally, the layer translates in both directions as necessary between the two modelsOne way of organizing the design of the ANTICORRUPTION LAYER is as a combination of FACADES, ADAPTERS (both from Gamma et al. 1995), and translators, along with the communication and transport mechanisms usually needed to talk between systems.We often have to integrate with systems that have large, complicated, messy interfaces. This is an implementation issue, not an issue of conceptual model differences that motivated the use of ANTICORRUPTION LAYERS, but it is a problem you'll encounter trying to create them. Translating from one model to another (especially if one model is fuzzy) is a hard enough job without simultaneously dealing with a subsystem interface that is hard to talk to. Fortunately, that is what FACADES are for.A FACADE is an alternative interface for a subsystem that simplifies access for the client and makes the subsystem easier to use. Because we know exactly what functionality of the other system we want to use, we can create a FACADE that facilitates and streamlines access to those features and hides the rest. The FACADE does not change the model of the underlying system. It should be written strictly in accordance with the other system's model. Otherwise, you will at best diffuse responsibility for translation into multiple objects and overload the FACADE and at worst end up creating yet another model, one that doesn't belong to the other system or your own BOUNDED CONTEXT. The FACADE belongs in the BOUNDED CONTEXT of the other system. It just presents a friendlier face specialized for your needs.An ADAPTER is a wrapper that allows a client to use a different protocol than that understood by the implementer of the behavior. When a client sends a message to an ADAPTER, it is converted to a semantically equivalent message and sent on to the "adaptee." The response is converted and passed back. I'm using the term adapter a little loosely, because the emphasis in Gamma et al. 1995 is on making a wrapped object conform to a standard interface that clients expect, whereas we get to choose the adapted interface, and the adaptee is probably not even an object. Our emphasis is on translation between two models, but I think this is consistent with the intent of ADAPTER.For each SERVICE we define, we need an ADAPTER that supports the SERVICE'S interface and knows how to make equivalent requests of the other system or its FACADE.The remaining element is the translator. The ADAPTER'S job is to know how to make a request. The actual conversion of conceptual objects or data is a distinct, complex task that can be placed in its own object, making them both much easier to understand. A translator can be a lightweight object that is instantiated when needed. It needs no state and does not need to be distributed, because it belongs with the ADAPTER(S) it serves.
- Integration is expensive.Integration is not always required.Decouple bounded contexts from each others.When No sharing of logic is required.If No sharing of data is required.
- Depending on their goals in interacting with the elephant, the various blind men may still be able to make progress, even if they don't fully agree on the nature of the elephant. If no integration is required, then it doesn't matter that the models are not unified. If they require some integration, they may not actually have to agree on what an elephant is, but they will get a lot of value from merely recognizing that they don't agree. This way, at least they don't unknowingly talk at cross-purposes
- Depending on their goals in interacting with the elephant, the various blind men may still be able to make progress, even if they don't fully agree on the nature of the elephant. If no integration is required, then it doesn't matter that the models are not unified. If they require some integration, they may not actually have to agree on what an elephant is, but they will get a lot of value from merely recognizing that they don't agree. This way, at least they don't unknowingly talk at cross-purposes
- Crude Model:The unification of the various elephant models is easier than most such mergers. Unfortunately, it is the exception when two models purely describe different parts of the whole, although this is often one aspect of the difference. Matters are more difficult when two models are looking at the same part in a different way. If two men had touched the trunk and one described it as a snake and the other described it as a fire hose, they would have had more difficulty. Neither can accept the other's model, because it contradicts his own experience. In fact, they need a new abstraction that incorporates the "aliveness" of a snake with the water-shooting functionality of a fire hose, but one that leaves out the inapt implications of the first models, such as the expectation of possibly venomous fangs, or the ability to be detached from the body and rolled up into a compartment in a fire truck.Even though we have combined the parts into a whole, the resulting model is crude. It is incoherent, lacking any sense of following contours of an underlying domain. New insights could lead to a deeper model in a process of continuous refinement. New application requirements can also force the move to a deeper model. If the elephant starts moving, the "tree" theory is out, and our blind modelers may break through to the concept of "legs."Deeper Model:This second pass of model integration tends to slough off incidental or incorrect aspects of the individual models and creates new concepts—in this case, "animal" with parts "trunk," "leg," "body," and "tail"—each of which has its own properties and clear relationships to other parts. Successful model unification, to a large extent, hinges on minimalism. An elephant trunk is both more and less than a snake, but the "less" is probably more important than the "more." Better to lack the water-spewing ability than to have an incorrect poison-fang feature.
- Show the initial domain here.
- 1- Show the local match output UML here.2- Example of the and
- 1- Show the local match output UML here.2- Example of the and
- 1- Show the local match output UML here.2- Example of the and
- The List Example:The Method Return Type Example:List<CrossNumber> candidateCrossNumbers = globalCrossGeneticMatchResultReader.retrieveDistinctCandidateCrosses (selectedChildGlobalMatchRunsList,true,true);The Method Parameters Example:
- The List Example:The Method Return Type Example:List<CrossNumber> candidateCrossNumbers = globalCrossGeneticMatchResultReader.retrieveDistinctCandidateCrosses (selectedChildGlobalMatchRunsList,true,true);The Method Parameters Example:
- 1- Behavior encapsulation can either be done in a default entity serviceor in a base parent model.2- Example of common Behaviour are the basic CRUD operations. 3- Every group of Entities can have their own persistence technology.Examples from MI:1- DeafultEntityService2- EntityService interface.
- 1- Behavior encapsulation can either be done in a default entity serviceor in a base parent model.2- Example of common Behaviour are the basic CRUD operations. 3- Every group of Entities can have their own persistence technology.Examples from MI:1- DeafultEntityService2- EntityService interface.