Domain-Driven Design

Editor's Notes

• #4: “Domain-Driven Design Quickly”: “Consider car manufacturing as a metaphor. The workers involved in auto manufacturing may specialize in producing parts of the car, but in doing so they often have a limited view of the entire car manufacturing process. They start viewing the car as a huge collection of parts which need to fit together, but a car is much more than that. A good car starts with a vision. It starts with carefully written specifications. And it continues with design. Lots and lots of design. Months, maybe years of time spent on design, changing and refining it until it reaches perfection, until it reflects the original vision. The processing design is not all on paper. Much of it includes doing models of the car, and testing them under certain conditions to see if they work. The design is modified based on the testing results. The car is sent to production eventually, and the parts are created and assembled together. Software development is similar. We can’t just sit down and type code. We can do that, and it works well for trivial cases . But we cannot create complex software like that.” Mention about the Waterfall and the Agile methodologies and how DDD can illuminate weak areas of XP.
• #5: Problem is: - you want to develop application and you dive into complexity - core problem of the whole is the Domain - For example "Banking" - Developers doesn't like to learn much about the bussiness... Maybe to give programming tools to the bank people? Developer stand with bussines guy near whiteboard. How this process looks like? What is the solution? Where to start?
• #6: Domain-driven design (DDD) is an approach to the design of software, based on the two premises [1]: that complex domain designs should be based on a model, and that for most software projects, the primary focus should be on the domain and domain logic (as opposed to the particular technology used to implement the system). Model in the Domain Driven Design Model and the design shape each other Model is language for team members Model is knowledge Ingredients of Effective Modeling Binding the model and implementation Cultivating a language based on the model Developing a knowledge-rich model Distilling the model Brainstorming and experimenting
• #7: Talk about need for some common language. Mention about the jargon of experts and develpers and that misunderstanding leads to project failure. A core principle of domain-driven design is to use a language based on the model.
• #8: A 110% rule.
• #9: A 110% rule.
• #10: A 110% rule.
• #12: “Remember, one of the consequences of this pattern is that you can't migrate to another design approach except by replacing entire applications.” The bottom line is this: If the architecture isolates the domain-related code in a way that allows a cohesive domain design loosely coupled to the rest of the system, then that architecture can probably support domain-driven design.
• #13: User Interface (Presentation Layer) Responsible for presenting information to the user and interpreting user commands. Application Layer This is a thin layer which coordinates the application activity. It does not contain business logic. It does not hold the state of the business objects, but it can hold the state of an application task progress. Domain Layer This layer contains information about the domain. This is the heart of the business software. The state of business objects is held here. Persistence of the business objects and possibly their state is delegated to the infrastructure layer. Infrastructure Layer This layer acts as a supporting library for all the other layers. It provides communication between layers, implements persistence for business objects, contains supporting libraries for the user interface layer, etc. For example, a typical, the interaction of the application, domain and infrastructure could look like this. The user wants to book a flights route, and asks an application service in the application layer to do so. The application tier fetches the relevant domain objects from the infrastructure and invokes relevant methods on them, e g to check security margins to other already booked flights. Once the domain objects have made all checks and updated their status to “decided”, the application service persists the objects to the infrastructure.
• #14: Talk about the diagram and a bit about the relations… Mention about each of the blocks: Associations Entities Value Objects Services Modules Aggregates Factories Repositories
• #15: Entities Identity Creation of unique identity If we were to implement the concept of a Person using a software program, we would probably create a Person class with a series of attributes: name, date of birth, place of birth, etc. It is important for two objects with different identities to be to be easily distinguished by the system, and two objects with the same identity to be considered the same by the system.
• #16: For fun: “Let’s consider a drawing application. The user is presented a canvas and he can draw any points and lines of any thickness, style and color. It is useful to create a class of object named Point, and the program could create an instance of this class for each point on the canvas. Such a point would contain two attributes associated to screen or canvas coordinates. Is it necessary to consider each point as having an identity? Does it have continuity? It seems that the only thing that matters for such an object is its coordinates.” An object that is used to describe certain aspects of a domain, and which does not have identity, is named Value Object. It is highly recommended that value objects be immutable. Immutability. Example is flight code. One golden rule is: if Value Objects are shareable, they should be immutable.
• #17: 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 OBJECT.
• #18: Such an object does not have an internal state, and its purpose is to simply provide functionality for the domain. The assistance provided by a Service can be a significant one, and a Service can group related functionality which serves the Entities and the Value Objects. It is much better to declare the Service explicitly, because it creates a clear distinction in the domain, it encapsulates a concept. It creates confusion to incorporate such functionality in an Entity or Value Object because it won’t be clear what those objects stand for. 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.
• #19: For a large and complex application, the model tends to grow bigger and bigger. The model reaches a point where it is hard to talk about as a whole, and understanding the relationships and interactions between different parts becomes difficult. For that reason, it is necessary to organize the model into modules. Modules are used as a method of organizing related concepts and tasks in order to reduce complexity. It is widely accepted that software code should have a high level of cohesion and a low level of coupling. While cohesion starts at the class and method level, it can be applied at module level.
• #20: Domain objects go through a set of states during their life time. They are created, placed in memory and used in computations, and they are destroyed. In some cases they are saved in permanent locations, like a database, where they can be retrieved from some time later, or they can be archived. Aggregate is a domain pattern used to define object ownership and boundaries. Factories and Repositories are two design patterns which help us deal with object creation and storage. Therefore, use Aggregates. An Aggregate is a group of associated objects which are considered as one unit with regard to data changes. The Aggregate is demarcated by a boundary which separates the objects inside from those outside. Each Aggregate has one root. The root is an Entity, and it is the only object accessible from outside. The root can hold references to any of the aggregate objects, and the other objects can hold references to each other, but an outside object can hold references only to the root object. If there are other Entities inside the boundary, the identity of those entities is local, making sense only inside the aggregate. If objects of an Aggregate are stored in a database, only the root should be obtainable through queries. The other objects should be obtained through traversal associations. Objects inside an Aggregate should be allowed to hold references to roots of other Aggregates. The root Entity has global identity, and is responsible for maintaining the invariants. Internal Entities have local identity.
• #21: Creation of an object can be a major operation in itself, but complex assembly operations do not fit the responsibility of the created objects. Combining such responsibilities can produce ungainly designs that are hard to understand. Making the client direct construction muddies the design of the client, breaches encapsulation of the assembled object or AGGREGATE, and overly couples the client to the implementation of the created object. Shift the responsibility for creating instances of complex objects and AGGREGATES to a separate object, which may itself have no responsibility in the domain model but is still part of the domain design. Provide an interface that encapsulates all complex assembly and that does not require the client to reference the concrete classes of the objects being instantiated. Create entire AGGREGATES as a piece, enforcing their invariants. There are many ways to design FACTORIES. Several special-purpose creation patterns— FACTORY METHOD, ABSTRACT FACTORY, and BUILDER—were thoroughly treated in Gamma et al. 1995. The two basic requirements for any good FACTORY are: 1. Each creation method is atomic and enforces all invariants of the created object or AGGREGATE. A FACTORY should only be able to produce an object in a consistent state. For an ENTITY, this means the creation of the entire AGGREGATE, with all invariants satisfied, but probably with optional elements still to be added. For an immutable VALUE OBJECT, this means that all attributes are initialized to their correct final state. If the interface makes it possible to request an object that can't be created correctly, then an exception should be raised or some other mechanism should be invoked that will ensure that no improper return value is possible. 2. The FACTORY should be abstracted to the type desired, rather than the concrete class(es) created. The sophisticated FACTORY patterns in Gamma et al. 1995 help with this. Reconstituting Stored Objects An ENTITY FACTORY used for reconstitution does not assign a new tracking ID. A FACTORY reconstituting an object will handle violation of an invariant differently.
• #22: To do anything with an object, you have to hold a reference to it. How do you get that reference? Creating and/or traversing is not the best way – you need Repository! Adding traversing code to your infrastructure kills model. Important: Any object internal to an AGGREGATE is prohibited from access except by traversal from the root. Problem: “” A subset of persistent objects must be globally accessible through a search based on object attributes. Such access is needed for the roots of AGGREGATES that are not convenient to reach by traversal. They are usually ENTITIES, sometimes VALUE OBJECTS with complex internal structure, and sometimes enumerated VALUES. Providing access to other objects muddies important distinctions. Free database queries can actually breach the encapsulation of domain objects and AGGREGATES. Exposure of technical infrastructure and database access mechanisms complicates the client and obscures the MODEL-DRIVEN DESIGN. For each type of object that needs global access, create an object that can provide the illusion of an in-memory collection of all objects of that type. Set up access through a well-known global interface. Provide methods to add and remove objects, which will encapsulate the actual insertion or removal of data in the data store. Provide methods that select objects based on some criteria and return fully instantiated objects or collections of objects whose attribute values meet the criteria, thereby encapsulating the actual storage and query technology. Provide REPOSITORIES only for AGGREGATE roots that actually need direct access. Keep the client focused on the model, delegating all object storage and access to the REPOSITORIES. REPOSITORIES have many advantages, including the following: * They present clients with a simple model for obtaining persistent objects and managing their life cycle. * They decouple application and domain design from persistence technology, multiple database strategies, or even multiple data sources. * They communicate design decisions about object access. * They allow easy substitution of a dummy implementation, for use in testing (typically using an in-memory collection). The REPOSITORY encapsulates the underlying data store.
• #23: Relationship with Factories Repository uses Factory to reconsistute User Uses Repostitory to save new one, but factory creates that object Repository and Relational database
• #24: “Refactoring is the process of redesigning the code to make it better without changing application behavior. Refactoring is usually done in small, controllable steps, with great care so we don’t break functionality or introduce some bugs. After all, the purpose of refactoring is to make the code better not worse. Automated tests are of great help to ensure that we haven’t broken anything.” Refactoring toward deeper insight is not the same kind as technical refactoring. We could not have patterns of doing it. “One of the first things we are taught about modeling is to read the business specifications and look for nouns and verbs. The nouns are converted to classes, while the verbs become methods. This is a simplification, and will lead to a shallow model.” “Sophisticated domain models are seldom developed except through an iterative process of refactoring, including close involvement of the domain experts with developers interested in learning about the domain.” Bring Key Concepts Into Light “Refactoring is done in small steps. The result is also a series of small improvements. There are times when lots of small changes add very little value to the design, and there are times when few changes make a lot of difference. It’s a Breakthrough.”
• #25: Constraint For example of Constraint talk about Placing the Constraint into a separate method has the advantage of making it explicit. Process “Processes are usually expressed in code with procedures. We won’t use a procedural approach, since we are using an objectoriented language, so we need to choose an object for the process, and add a behavior to it. The best way to implement processes is to use a Service. If there are different ways to carry out the process, then we can encapsulate the algorithm in an object and use a Strategy. Not all processes should be made explicit. If the Ubiquitous Language specifically mentions the respective process, then it is time for an explicit implementation.” Specification (Rules by Jimmy Nilsson) “Simply said, a Specification is used to test an object to see if it satisfies a certain criteria.” Talk about Rules….. “The Specification is used to test objects to see if they fulfill some need, or if they are ready for some purpose. It can also be used to select a certain object from a collection, or as a condition during the creation of an object.”
• #26: Talk about the enterprise projects and contribution of many teams work into it and intersection with domain. Created module by one team and change to it by developer from other breaks the model. “The first requirement of a model is to be consistent, with invariable terms and no contradictions.”
• #27: “Each model has a context. When we deal with a single model, the context is implicit. We do not need to define it. When we create an application which is supposed to interact with other software, for example a legacy application, it is clear that the new application has its own model and context, and they are separated from the legacy model and its context. They cannot be combined, mixed, or confused. But when we work on a large enterprise application, we need to define the context for each model we create.” A model should be small enough to be assigned to one team. Continuous Integration Continuous Integration is based on integration of concepts in the model, then finding its way into the implementation where it is tested. Any inconsistency of the model can be spotted in the implementation. Continuous Integration applies to a Bounded Context, it is not used to deal with relationships between neighboring Contexts. Context Map A Context Map is a document which outlines the different Bounded Contexts and the relationships between them. A Context Map can be a diagram like the one below, or it can be any written document. The level of detail may vary. What it is important is that everyone working on the project shares and understands it.
• #28: Shared Kernel The purpose of the Shared Kernel is to reduce duplication, but still keep two separate contexts. Designate some subset of the domain model that the two teams agree to share. Of course this includes, along with this subset of the model, the subset of code or of the database design associated with that part of the model. This explicitly shared stuff has special status, and shouldn’t be changed without consultation with the other team. Customer-Supplier (for example reporting to some functionality and the functionality itself) There are times when two subsystems have a special relationship: one depends a lot on the other. The contexts in which those two subsystems exist are different, and the processing result of one system is fed into the other. They do not have a Shared Kernel, because it may not be conceptually correct to have one, or it may not even be technically possible for the two subsystems to share common code. The two subsystems are in a Customer-Supplier relationship. Addition to example: “The reporting team should play the customer role, while the eshopping team should play the supplier role.” Conformist This is much like the Shared Kernel, but there is an important difference. The customer team cannot make changes to the kernel. They can only use it as part of their model, and they can build on the existing code provided. Anticorruption Layer This deals with legacy systems. Almost about the Homecare Link project:  “Another method of interaction is the database. The external system works with data stored in a database. The client system is supposed to access the same database. In both cases we are dealing with primitive data being transferred between the systems. While this seems to be fairly simple, the truth is that primitive data does not contain any information about the models. We cannot take data from a database and treat it all as primitive data. There is a lot of semantics hidden behind the data. A relational database contains primitive data related to other primitive data creating a web of relationships. The data semantics is very important, and needs to be considered. The client application can’t access the database and write to it without understanding the meaning of the data used. We see that parts of the external model are reflected in the database, and make their way into our model.” We should build an Anticorruption Layer which stands between our client model and the external one. This layer works as a two way translator between two domains and languages. Separate Way Could be used when the CI makes too much difficalties. The Separate Ways pattern addresses the case when an enterprise application can be made up of several smaller applications which have little or nothing in common from a modeling perspective. There is a single set of requirements, and from the user’s perspective this is one application, but from a modeling and design point of view it may done using separate models with distinct implementations. Open Host Service The solution is to see the external subsystem as a provider of services. If we can wrap a set of Services around it, then all the other subsystems will access these Services, and we won’t need any translation layer. The difficulty is that each subsystem may need to interact in a specific way with the external subsystem, and to create a coherent set of Services may be problematic.
• #29: Invisibility of saving – key concept for Infrastructure
• #30: Where to save: Memory, File system, Object db, Relational db Data mapper or ORM ORM Classification: Inheritance Starting point Quering language Good support for Database operations: aggregate, ordering, grouping, etc Other Classification: Differend RDMS Caching Transactions Open code? ORM Identity Map Unit Of Work Lazy load
• #31: NHibernate provides all the features required to quickly build an advanced persistence layer in code. v
• #32: Advantages for design More client control More Interfaces and Fabrics More concrete Low coupling Other advantages Another version of API Long term support Documentation Like smart compiler Disadvantages UI & Database testing You feel too much safe Possilitity to lose whole visibility More code to maintain Fake, Stub, Mock – mention about these also! SOA (Service-oriented architecture) Generally speaking, SOA is a flexible set of design principles used during the phases of systems development and integration. AOP (Aspect-oriented programming) In computing, aspect-oriented programming (AOP) is a programming paradigm in which secondary or supporting functions are isolated from the main program's business logic. It aims to increase modularity by allowing the separation of cross-cutting concerns, forming a basis for aspect-oriented software development.
• #35: Very recently, web development platforms have begun to mature enough to make web development productive enough for DDD, and there are a number of positive trends. For example, SOA, when it is used well, provides us a very useful way of isolating the domain.