Supple, or elegant and flexible, design is a complement to Deep Modelling. While deep modelling is about digging out domain concepts with the domain experts, and reflecting those concepts in code, Supple Design is about building that code in a way that is easy to understand, modify and extend, in sum: code that is maintainable.
If we want to maintain speed of development as the project grows, we must design code that is a pleasure to work with, code that invites change. Otherwise the code will be a mess, where a small change can aggravate or break something: developers will dread to look at it, let alone work with it.
Eric Evans came up with a set of patterns that can help achieve this supple design.
Continue reading “DDD.10 – Supple Design” →
Implicit concepts are concepts that exist but , for some reason, the domain experts don’t talk about them explicitly. It takes some time until the developers actually realize the existence of those implicit concepts, by means of hints while discussing the model or at later stages, when several other concepts are already set in place.
Continue reading “DDD.9 – Making implicit concepts explicit” →
The third part of the book starts in chapter 8 and talks about refactoring.
Refactoring towards deeper insight has the objective of having a domain model that closely reflects the domain. This makes the software more in tune with what the domain experts think and to the users current and future needs.
Continue reading “DDD.8 – Refactoring toward deeper insight / Breakthrough” →
This chapter is a long example of how project architecture may evolve.
There aren’t many new concepts approached, nevertheless, in the end of the chapter there are three interesting design patterns mentioned:
- Anti-corruption layer
- Enterprise segments
Continue reading “DDD.7 – Using the language” →
There are three main objects that can control the life-cycle of a domain object:
- Aggregates: Hold several objects in a root object and can control their creation, manipulation, query and deletion;
- Factories: Create new objects with a set of data;
- Repositories: Recreate persisted objects from queried data, possibly delegating the reconstruction of the actual object instance to a factory.
Continue reading “DDD.6 – The lifecycle of a domain object” →
A model is expressed in code by several patterns of model elements:
- Value objects
Continue reading “DDD.5 – A model expressed in software” →
In order to easily identify, understand and manipulate the code that reflects the domain, we need to isolate it from all the support code, the code that allows for user interaction (views, controllers) and the code that allows for data persistence and retrieval.
The most widely used and easy to understand approach is to isolate the code into layers:
- User interface: Views to interact with the user;
- Application: Controllers to specify use cases;
- Domain: Business rules that reflect the model;
- Infrastructure: Persistence, queues, … ;
Continue reading “DDD.4 – Isolating the domain” →
The implementation design must be easily and accurately mapped to the model, otherwise the model is of little use. Easier said than done though.
Anyway, the process should start by creating a simple but very accurate design of a small part of the domain. This inicial design should then be revisited, improved, incremented and re-factored in order to reflect a bigger set of the domain, in a way more suited to the actual implementation.
Continue reading “DDD.3 – Binding model and implementation” →
As in any activity, fast, easy and clear communication is essential for a good performance.
In a software development project, both domain experts and developers have their own language, with its own jargon and specificities. Both team member types are usually unaware of the others language, so it must be created a common language that everyone can understand without any ambiguity.
Continue reading “DDD.2 – Communication and the use of language” →
Developers and Domain Experts collaborate, discussing the Domain Experts knowledge, distilling it into all, and only, the knowledge relevant to the project.
The objective is to end up with a model of what the application should do, how it should do it, and what the technical implementation should be.
Continue reading “DDD.1 – Crunching knowledge” →