blocks|key|2445743|text|就这么做。不要让任何先入为主的条件阻止你开始练习它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2445744|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Just do it. Don't let any preconceived condition prevents you from starting to practice it.

blocks|key|2445792|text|我读了蓝色的“埃文斯”和红色的“弗农”，偶尔也会在StackOverflow上看到这个标签。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2445793|埃文斯的这本书在某些方面非常高水平，涵盖的不仅仅是代码。Vernon的这本书介绍了DDD的构建块，一次一个项目，并以一个虚构的软件产品的示例为例：|2445794|Domain-driven+Design:+Tackling+Complexity+in+the+Heart+of+Software|offset|length|2445795|Implementing+Domain-Driven+Design|2445796|还有一段视频：|2445797|Eric+Evans:+What+I've+learned+about+DDD+since+the+book|2445798|对于设计模式，DDD材料引用了大量的设计模式。一些现有的设计模式与DDD配合得很好。你可以在遇到它们时拿起它们，你不一定需要事先知道它们。在学习设计模式时要避免的一件事是，不要尝试强制使用它们，它们有其用途，但你会看到许多开发人员试图在不需要它们的地方强制使用新学到的设计模式。|2445799|entityMap|0|LINK|mutability|MUTABLE|url|http://www.amazon.co.uk/Domain-driven-Design-Tackling-Complexity-Software/dp/0321125215/ref=sr_1_2?ie=UTF8&qid=1373965206&sr=8-2&keywords=ddd|1|http://www.amazon.co.uk/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577/ref=sr_1_1?ie=UTF8&qid=1373965206&sr=8-1&keywords=ddd|2|http://www.youtube.com/watch?v=lE6Hxz4yomA^0|0|0|0|1U|0|0|0|X|1|0|0|0|1I|2|0|0^^$0|@$1|2|3|4|5|6|7|11|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|12|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|13|8|@]|9|@$F|14|G|15|1|16]]|A|$]]|$1|H|3|I|5|6|7|17|8|@]|9|@$F|18|G|19|1|1A]]|A|$]]|$1|J|3|K|5|6|7|1B|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1C|8|@]|9|@$F|1D|G|1E|1|1F]]|A|$]]|$1|N|3|O|5|6|7|1G|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]]|Q|$R|$5|S|T|U|A|$V|W]]|X|$5|S|T|U|A|$V|Y]]|Z|$5|S|T|U|A|$V|10]]]]

I read the blue book [Evans], the red book [Vernon] and occasionally pop into this tag on StackOverflow. 

The book by Evans is very high level in some aspects and covers more than just code. The book by Vernon covers the building blocks of DDD an item at a time, using examples from a fictitious software product as an example:

<a href="http://www.amazon.co.uk/Domain-driven-Design-Tackling-Complexity-Software/dp/0321125215/ref=sr_1_2?ie=UTF8&amp;qid=1373965206&amp;sr=8-2&amp;keywords=ddd" rel="noreferrer">Domain-driven Design: Tackling Complexity in the Heart of Software</a>

<a href="http://www.amazon.co.uk/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577/ref=sr_1_1?ie=UTF8&amp;qid=1373965206&amp;sr=8-1&amp;keywords=ddd" rel="noreferrer">Implementing Domain-Driven Design</a>

There's also the video:

<a href="http://www.youtube.com/watch?v=lE6Hxz4yomA" rel="noreferrer">Eric Evans: What I've learned about DDD since the book</a>

As for design patterns, the DDD material refers to lots of design patterns. Some existing design patterns work very well with DDD. You can pick these up as you encounter them, you wont necessarily need to know them in advance. One thing to avoid when learning design patterns, is to not try and force their use, they have their uses but you see a lot of developers trying to force the use of newly learnt design patterns in places where they aren't required.

blocks|key|2044555|text|这是一个有点晚的答案，但我想说的是，模式并不是一些固定的、照搬不变的终极解决方案。它们是解决通用问题的通用方法，如果您愿意，可以作为指南。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2044556|在DDD中，您为特定问题提供了特定解决方案。如果您能够识别实现中的模式，您将获得更深入和更结构化的理解。如果你能看到需要一些模式的问题，你就有可能解决它的方法。但要注意，仅通过模式查看问题可能会导致次优解决方案。|2044557|了解和理解模式将帮助您以更有效的方式将有关实现细节的知识传达给其他开发人员。比如“这是工作单元”，而不是“这个对象持有对我们在这个事务中操作的对象的引用，并跟踪它们的状态，这样我们就可以一次提交所有的更改”。|2044558|除此之外，更重要的是理解并遵循SOLID和DDD原则来构建成功的领域模型。|2044559|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

This is a bit late answer, but i want to say that patterns are not some set-in-stone follow-to-the-letter ultimate solutions. They are generic approaches to generic problems, guidelines if you want.

In DDD you provide specific solution to specific problems. If you can recognize patterns in your implementation you will gain a bit deeper and more structured understanding. If you can see problems calling for some patterns, you will have possible approaches for solving it. But beware, looking at the problem solely through patterns might lead to suboptimal solutions. 

Knowing and understanding patterns will help you convey knowledge about implementation details to other developer in more efficient manner.
Like "this is Unit of Work" instead of "this object holds references to objects we act upon in this transaction and tracks their state so we can commit all changes at once".

Other than that, it is more important that you understand and follow SOLID and DDD principles to build successful domain models.

I have a copy of Head First Design Patterns and I read through a few of the patterns in there. Now is Domain driven design a substitute to the traditional design patterns or does it build upon it? If its the latter, do I need to be a Design patterns expert before I attempt to learn domain driven design? What is the recommended path to DDD?

Do I need to be a design patterns expert before I dive into Domain Driven Design?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我有一份Head First设计模式的副本，我通读了其中的一些模式。现在，领域驱动设计是传统设计模式的替代品，还是它的基础？如果是后者，在我尝试学习领域驱动设计之前，我需要成为设计模式专家吗？推荐的DDD路径是什么？

问在深入领域驱动设计之前，我需要成为一名设计模式专家吗？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在深入领域驱动设计之前，我需要成为一名设计模式专家吗？EN