More on this book
Community
Kindle Notes & Highlights
by
Evans Eric
Started reading
June 15, 2019
A feature common to the successes was a rich domain model that evolved through iterations of design and became part of the fabric of the project.
Software development teams facing complex domains can use this framework to approach domain-driven design systematically.
good design can create opportunities to exploit those complex features.
Yet the most significant complexity of many applications is not technical. It is in the domain itself, the activity or business of the user.
1. For most software projects, the primary focus should be on the domain and domain logic. 2. Complex domain designs should be based on a model.
Domain-driven design is both a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains.
These two practices are prerequisites for applying the approach in this book. 1. Development is iterative. Iterative development has
been advocated and practiced for decades, and it is a cornerstone of Agile development methods. There are many good discussions in the literature of Agile development and Extreme Programming (or XP), among them, Surviving Object-Oriented Projects (Cockburn 1998) and Extreme Programming Explained (Beck 1999). 2. Developers and domain experts have a close relationship. Domain-driven design crunches a huge amount of knowledge into a model that reflects deep insight into the domain and a focus on the key concepts. This is a collaboration between those who know the domain and those who know how to
...more
I will use XP as the basis for discussion of the interaction of design and process.
Instead, the Agile processes, such as XP, emphasize the ability to cope with change and uncertainty.
XP process assumes that you can improve a design by refactoring, and that you will do this often and rapidly.
Are we properly using agile process in development?
A sophisticated approach to domain modeling within the context of an Agile development process will accelerate development.
Part I defines terms and gives an overview of the implications of using the domain model to drive communication and design.
bridging the gap between models and practical, running software.
the kinds of decisions that keep the model and implementation aligned with each other, each reinforcing the other’s effectiveness.
That understanding comes from diving in, implementing an initial design based on a probably naive model, and then transforming it again and again.
This section explores a triad of principles that apply to the system as a whole: context, distillation, and large-scale structure.
Supplemental materials can be found at http://domaindrivendesign.org,
To-study, with real code example
the biggest gains come when a team joins together to apply a domain-driven design approach and to move the domain model to the project’s center of discourse.
A model is a simplification. It is an interpretation of reality that abstracts the aspects relevant to solving the problem at hand and ignores extraneous detail.
소프트웨어의 핵심은 도메인 모델을 만드는 것에 있다. 인공지능, 로봇, VR과 같은 것들도 결국엔 Infrastructure 이다. 이러한 Infrastructure들을 늘려가는 것, Domain 모델을 잘 만들어가는 것이 기술 혁신의 목표가 아닐까
That subject area to which the user applies the program
The domain of the software
the idea that the diagram is intended to convey.
not a matter of making as “realistic” a model as possible. Even in a domain of tangible real-world things, our model is an artificial creation.
Domain Modeling
The model and the heart of the design shape each other.
The model is the backbone of a language used by all team members.
The model is distilled knowledge.
The heart of software is its ability to solve domain-related problems for its user.
There are systematic ways of thinking that developers can employ to search for insight and produce effective models.
They always involved “nets” and various details about them.
A few months later the PCB engineers had a rich tool that exceeded their expectations.
Software Engineers are translator between domain model and information system.
Binding the model and the implementation.
Cultivating a language based on the model.
Developing a knowledge-rich model.
Distilling the model.
Brainstorming and experimenting.
They try one organizing idea after another, searching for the simple view that makes sense of the mass.
In the old waterfall method, the business experts talk to the analysts, and analysts digest and abstract and pass the result along to the programmers, who code the software. This approach fails because it completely lacks feedback.
Good programmers will naturally start to abstract and develop a model that can do more work.
