1. 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.

2. (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

3. 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

4. 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.