Это - действительно DDD?
Существуют различные способы получить представление о вашей умной контрактной деятельности.
Вы можете проверить https://etherscan.io/ и найти список транзакций. Это может быть очень полезно, если вам нужно просматривать отдельные транзакции. Etherscan показывает ряд транзакций и другую полезную информацию.
Если вам не хватает Etherscan, есть другие приложения. Вы можете проверить https://scout.cool/ и https://analyther.com . Analyther работает с любым умным контрактом и предоставляет вам подробные графики транзакций, событий, активных пользователей и т. Д. Он создает отчеты, подобные этим: 
3 ответа
DDD s new enough (at least in some senses) that it may be a little early to say exactly "how it's done." The idea's been around for a fair long while, though, although we didn't make up a cool name for it.
In any case, the short answer (IMAO) is "yes, but...." The idea of doing a domain-driven design is to model the domain very explicitly. What you're looking at is a domain model, which is to say an object-oriented model that describes the problem domain in the problem domain's language. The idea is that a domain model, since it models the "real world", is relatively insensitive to change, and also tends to localize change. So, if for example your idea of what an Employee is changes, perhaps by adding a mailing address as well as a physical address, then those changes would be relatively localized.
Once you have that model, though, you have what I maintain are architectural decisions still to be made. For example, you have the unimplemented persistence layer, which might indeed be simply construction of SQL. It could also be a Hibernate layer, or use Python pickling, or even be something wild like a Google AppEngine distributed table structure.
The thing is, those decisions are made separately, and with other rationales, than the domain modeling decisions.
Something I've experimented with to some good result is doing the domain model in Python and then building a simulator with it instead of implementing the final system. That makes for something the customer can experiment with, and also potentially allows you to make quantitative estimates about the things the final implementation must determine.
Домен-управляемый дизайн действительно прост. Он говорит: заставьте ваши классы Model отражать реальный мир. Поэтому, если у вас есть Employees, есть класс Employee и убедитесь, что он содержит свойства, которые придают ему «Employee-ness».
Вопрос, который вы задаете, НЕ о DDD, а скорее об архитектуре класса в целом. Я думаю, что вы правильно ставите под сомнение некоторые решения относительно классов, которые вы просматриваете, но это не имеет отношения к DDD конкретно. Это больше относится к шаблонам проектирования ООП программирования в целом.
для меня то, что отличает DDD от «простого» дизайна, основанного на модели, - это понятие «совокупных корней», то есть приложению разрешено содержать только ссылки на агрегированные корни , и в целом у вас будет только репозиторий для агрегированного корневого класса, а не для классов, которые использует агрегированный корень
, это значительно очищает код; альтернативой являются репозитории для каждого класса модели, что является «просто» многоуровневым дизайном, а не DDD