Patterns, Domain-Driven Design (DDD), and Test-Driven Development (TDD) enable architects and developers to create systems that are robust and maintainable. While the examples in this guide are in C# and .NET, the principles can be used by developers using any language and IDE.
Вы уже прочитали DDD Эванса, PoEAA Фаулера, что-нибудь по методологии TDD, с уважением посмотрели на экземпляр книги "Банды Четырёх", который вы иногда берете в руки, чтобы проникнуться мудростью предков, и пытаетесь понять, как это всё применить на практике? Тогда обратите внимание на эту книгу. Тут показан подход конкретного разработчика к конкретной задаче с применением вышеуказанных методик. Эта книга - далеко не библия программиста, но она определенно наведет вас на некоторые мысли. Если есть возможность - читайте в оригинале, ибо переводчик явно перестарался. Продираться через введенные им русские аббревиатуры для общепринятых понятий достаточно сложно.
I really thought this will be about DDD. Unfortunately it wasn't. Author describes very detailed thinking process how his path to particular solution has looked. He starts with whole concept of application classes and others I was very brave and read everything w waiting for some ddd info. But on page 200 he wrote that we right now already described ddd and let's move to other topics. From now on reading book make physical hurt to me. Author describes everything patterns, orm, GUI, database even aspect developing has its own chapter. No no no. Please do not open this.
So far the best book on Domain-Driven Design. Jimmy Nilsson explains in great detail how he comes to the solution and what he thought about and discarded. Seeing how an application grows and understanding all the decisions on the way is a great help to build your own application. Even when you don’t build the same application, the ideas and approaches of the book can guide you.
I especially liked the situations when I didn’t agree with the solution. With the explanation in place while he chooses it, I could find the points where we differ and see how different approaches result in different outcomes. Designing software is not about right or wrong, but about decisions and their pros and cons.
I've read Eric Evans' book on domain driven design...but wanted someone's tae on the nuances of actually implementing Eric's domain patterns. This book is OK, but didn't go as far in the directions I might've wanted to see. Although the book says "with examples in C# and .NET) this should not be a barrier to Java folks. It reads just fine. My one disappointment is that it seems to be a walk through Jimmy's experiences without a good summary of issues/implementation concerns. He spent too much time on TDD and refactoring, rather than on nuances of certain patterns for my needs.
This book is hit and miss. Some parts I liked and found useful, while others seemed dated or I simply disagreed with. It's a good book for gaining exposure to things like domain-driven design, test-driven development, object-relational mapping, and dependency injection, but there are other books that go into deeper detail on each of these subjects. So I'd say check this book out if you're new to these topics but otherwise go to the books that this book references.
The Initial part was very impressive. But he sort of starts to discuss so many options and try to pick a simple solution and all of a sudden starts discussing some advanced concepts. I couldnt quite follow the middle part. I guess i will give it another try after reading Patterns of Enterprise Architecture and Domain Driven Design. Not sure whether i ll have time though.
Too little about DDD and too much about everything else. The focus of the book was quite broad - it touched TDD, Dependency injection and investigated NHibernate and other frameworks. I would much more prefer it to be more focused on the DDD and domain design. If you don't know anything about DDD, I would rather start with the Evans book.