• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Domain Driven Design Thoughts   Mat Holroyd
 

Domain Driven Design Thoughts Mat Holroyd

on

  • 461 views

 

Statistics

Views

Total Views
461
Views on SlideShare
454
Embed Views
7

Actions

Likes
0
Downloads
12
Comments
0

1 Embed 7

http://melbournepatterns.org 7

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

    Domain Driven Design Thoughts   Mat Holroyd Domain Driven Design Thoughts Mat Holroyd Presentation Transcript

    • Chapter 1 1. The language used between developers and domain experts should be one and the same. (a) Developers should thus learn the domain language, while domain experts will likely need to learn some software modelling terms to understand diagrams etc. that the developers construct. (b) The language should be reflected in communication between the techs and the domain experts, but should also be used amongst the techs and amongst the domain experts. (c) Benefits are: i. Umabiguous understanding amongst different teams. This saves time as people start on the same page.. ii. Explanations can be more consise as terms do not have to be explained. 2. If the language is not used ubquitously, then the lanuage, may have problems (inconsistencies, ambiguities, etc.). (a) Schisms may evolve when the language is fractured, which are when team members use terms differently but don't realize it. 3. A diagram is not the model. Rather, a diagram helps people visualize the domain, or parts of it, but it does and should not explain everything. (a) Detailed diagrams require effort to construct and effort to understand. (b) Although it may be tempting to created detailed UML, UML to code generation is limited to what that particular diagraming method can display. As UML has trouble conveying the meaning and intent of an object (for instance), then the diagram is already limited in how much of the domain it can display. 4. The detail should be in the code. Documents should complement the code and speech. (a) Documents that state what the code does explicitly are unnecessary. The codes is already explicit. Instead documents that are less detailed can serve to introduce someone to the code as code by itself can be overwhelming and hard to understand. (b) A document has costs associated with it, that should be understood. i. The language used and the model a document explains should be kept up to date, or the document should be archived. Chapter 3 1. Emphasis should be on increasing understaing, not on modelling per se. Understanding comes with doing, not thinking alone. (a) The dogma that the steps of a software cycle are separable and distinct, in so far as isolating teams therefrom can be beneficial, is untrue. The maleable logic that is software means unlimited solutions, with an enormous number of 'gotcha's'- analysts and designers will miss unforseen but very specific problems that the implementers will come across. (b) The implementers then have problems in negotiating these inevitable problems. They must come up with unsatisfactory solutions in the code; ignore parts of the model; or take time convincing the designers and/or analysists to redo the model, which may or may not solve the problem until once again it comes back to implementation. (c) In contrast to missing important problems, designers and analysist may waste time analyizing something that is trivial to implement. 2. Relevance of the model is of upmost importance. (a) A model with little relevance means the code is a mechanism that does useful things but with no explanation. Hence if a model does exist, changing it has no relevance to how the code should change. (b) Hence the model should be relevant to both the domain and the implementation. Serving one should not sacrifice the other.
    • (c) Suggested to design a proportion in a very literal way. Then revist to make it more natural to the software domain. Demand a single model even as gaining deeper insight. 3. Avoid implied abstractions. (a) If you create a system that does meaningful work, but has no meaningful name attached to it, change it. The system should be reexamined to gain insight into what is really going on. 4. Don't hide abstractions. (a) If the system treats part of the domain in a certain and specific way, don't hide it from the user. In all likelihood, if that system adheres to the principles of some other domain, then an informed user can take advantage of that. Hiding these details may cause confusion as the user gets unexpected behaviour. 5. Unempowered developers (insofar as the model is concerned) means the model will have less relevance to them then how it should be. (a) Designers with little implementing experience do not understand how easy the implementation can be changed to suit a change in the model. 6. Implementers need to know how to express the model in the code. (a) Hence coders need to know the model well. Contact with the domain experts is good. (b) Part II 1. Understand fundamentals of support Model driven design. (a) Knowing how it works means teams can compromise with competing priorities without sacrificing import gains. Chapter 4 1. The domain objects are likely to only make up a small part of the software system. (a) Their size is disproportional to their size. (b) Hence it can be easy to lose which objects in the whole system are the really important ones. 2. In OO languages, model-related concepts are imbedded in GUI, database and other, non- centralized components. (a) Easy to do in short run, but causes problems later on. Esentially the model is not 'in' a specific group of objects, rather the larger system is the model. Thus more of the system needs to change when the model changes. 3. Layered architecture helps model driven design, with the model layer separated. (a) Suggested that should have 4 layers i. Presentation layer (Show information to user, gets input from user) ii. Application layer (Coordinates tasks between model objects, but does no domain logic) iii. Domain layer (The heart of the system. Represents the domains concepts). iv. Infrastructure (Provides technical functionalities to higher layers, such as persistance as UI widgets). (b) The separation of the domain layer is crucial for domain driven design- it may be beneficial to combine other layers, or have multiple infrastructure layes for instance, as the context demands. (c) Once separated, the domain objects are free to express the domain in powerful ways. 4. Relating layers is a difficult task. (a) Frameworks help, as they usually provide either a design to separate layers in a well
    • understood way, or they provide classes that simplify supporting layers. (b) Becareful though, as frameworks should not be used excessively, or else there's a risk of constraining developers. 5. The domain layer is the domain model in code. (a) Hence other software concerns cannot be in the model level, as that would change what it is. 6. Smart UI can be a suitable replacement for heavy-weight domain driven design. (a) Smart UI have logic in the UI. i. Easy for beginner programmers; takes advantage of 4GL. ii. Falls down when domain is complex., as less reuse. (b) Using a flexible language does not mean a flexible program. If going to do smart UI, don't waste time with a low-level language- use the tools for the job. Conversely, for domain driven design need flexible languages like Java, C#. 7. Isolating a model in a layer helps maintain it, but faces threats on other fronts. (a) Other teams may have different models for the same domain. (b) Parts of the system may not be fully integrated into the model. Chapter 5 1. Entities (a) Things within the model whose identity matters. Seats in a stadium may or may not be entities, despite the fact that all seats are 'unique' in a real world sense. In a stadium event management program, the identity of a seat would matter if it was allocated seating. However, if its just general admission, its meaningless to include the identity of seats in the model (that is, identity does not matter, and thus they are not entities). (b) Entities may change over time, in terms of what object(s) represent them in the implementation. Conversely, the attributes of entity may be the same as another entity. Hence identifying an entity should not rely on attributes. (c) Note that using the reference of an object in languages like Java may not be good enough, as persistence and networking will break this. (d) May use a combination of attributes to create an identity (a key), but need to be careful. 2. Value objects (a) Things whose identity does not matter, only their value(s). They are used to describe things. For instance, the color red; the numbers 5 are value objects. (b) As a general rule, create a value object when you only care about the attributes of the element. (c) Value objects are easier to maintain then entities and lend themselves to optimizations that entities do not. (d) Value objects should be immutable. One advantage of this is they can be shared (performance). They can only be mutable if they are not shared. (e) Because identity of value objects does not matter, they can be freely copied wholy without concern for consequences. (f) Value objects should not have bidirectional relationships. The concept makes no sense. If model is asking for it, then maybe one of the value objects should actually be an entity. 3. Services (a) When an action does not naturally belong to any entities or value objects within the domain, creating a standalone service interface solve this problem in a simple way. (b) The service interface should be define in terms of other domain objects. (c) The operation should be stateless. That is, the service will not be affected by its history. (d) Services should be separated into their relevant layers. That is, technical services like email notification should be in the infrastructure, while exporting a list of accounts to a
    • file should be in the application layer. (e) Service can help reduce complexity as responsibility for particular actions is less likely to leak into application layer objects. (f) How a service is provided is so important as the design decision to create it in the first place. A singleton class can neatly act as a service provider. 4. Modules (a) Good tool to break up parts of a system. Low coupling and high cohesion can be explained with the ubiquitous language. i. High cohesion = easier to think about what a module does ii. Low coupling = easier to think about a module in isolation. (b) Separating the model layer into distinct modules is useful, but deviding the other layers into modules should be treated as separate cases. That is, the modules in other layers should not follow the modules in the model layer unless it is useful to do so. (c) Module names should be part of the ubiquitous language.