![]() ![]() Having alternatives helps you evaluate the pros and cons of each one and make better decisions. This variety of viewpoints can help you build candidate models for your design. Detect different wording or terminology used for the same concept/process/task because, quite often, different wording indicates different viewpoints/approaches for the same thing. What am I going to do with that model ? If I don’t know that, how can I know if the model I designed is useful ? Observe conversations that happen at business level or how different business experts (or non-experts, people from various departments) talk to you about the same issue. So, there are a few question we should ask ourselves when modeling business concepts. Each model may need different kind of information or information expressed in a different way. The task that our software is designed to implement. So, there may be several ways to model a business concept or entity (a document, a process, an operation, a role) but not all of them will make our life easier when they are going to be used for a specific task. Modeling is a tangible projection of a concept, suitable for the task it is going to be used at. The heart of DDD – Part 1: Understanding the (business) domain This is not one task, it can happen in many levels (from macroscopic to microscopic) and has several methodologies related to it (Event Storming is one of them but you don’t need to use it in order to be able to claim that you are following a DDD mentality). The core of DDD is focusing on the problem domain, its modeling and the discovery of bounded contexts within it as well as the importance of those things. are part of DDD but also that the core of DDD has to do with such low-level design details. No only making many people thing that concepts like “entity”, “value object” “repositories” etc. Unfortunately, in 2021, Derek Comartin talks again about the excessive emphasis that has been given to DDD’s tactical design. It is totally fine.Ībout a decade ago Eric Evans said that tactical patterns are overemphasized by people at the expense of the most important ideas in DDD. Instead of “entity” you may use the term “domain object”. For example, instead of a “repository” you may use the term “persistor”. Or you may use the patterns but you may name them anyway you like (or you see more appropriate based on their role in your architectural design). Some or all of them may not fit you problem or architectural design. You don’t have to use them (at least, not as they are used in Eric Evans’ book) just because you are following the mentality of DDD. Tactical patterns are there to set an example. The significant contribution of DDD is that it is enabling us to first think our problems as domain problems (business problems) and then as technical problems. They exist in the world of OOP before DDD. Concepts like “Entities”, “Value Objects”, “Repositories”, “Services”, referred as tactical patterns in DDD, are not discovered or originally proposed by DDD. Let’s start with a groundbreaking(?) discovery.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |