这是一个创建于 2646 天前的主题，其中的信息可能已经有所发展或是发生改变。
.net 领域驱动设计
涉及很多知识点
涉及很多知识点
第 1 条附言 · 2017-09-22 14:31:30 +08:00
 |
1
pming1 2017-09-21 15:31:47 +08:00
看 abp 项目和文档
|
 |
2
hantsy 2017-09-21 15:45:41 +08:00
这方面经典著作不少。。。
|
 |
3
Lenhoon 2017-09-21 17:04:35 +08:00
昨天三面就被问到这个，准备学习下
|
|
4
hantsy 2017-09-21 21:43:59 +08:00  4
1. Eric 的 DDD 一书是经典，虽然过去十几年，但它是 DDD 鼻祖。国内已经出版多次，有中文版本，和英文版本。
2. InfoQ 上有一个 DDD Quickly，同样有中文版本，免费。 3. Vaughn Vernon 的几本书对 DDD 进行延深，也是经典读物（我还没读过），https://vaughnvernon.co/?page_id=168，不过此人博客文章可以仔细阅读。 4. 作为 DDD 的延深阅读，可以了解 CQRS 和 Event Sourcing， 实现 Microservice 必备知识，http://cqrs.nu/ 这个网站不错 DDD 经典例子： 1. Eric 的 DDD 原书的例子是一个 Spring 程序。 2. Oracle 官方 Java EE 7 演示程序 https://javaee.github.io/cargotracker/，用 Java EE 7 重新实现了 Eric 原书例子。 3. https://github.com/VaughnVernon，Github 上有原书 IDDD （ Implement Domain Driven Design ）的 Java 和 C# Demo。 |
|
5
hantsy 2017-09-21 22:02:24 +08:00
另外微软有一本 CQRS Journey 也不错，可以免费下载，这个我没仔细看。
|
 |
6
qinxg 2017-09-21 22:12:30 +08:00
跟你一样有这个烦恼
|
 |
7
WispZhan 2017-09-21 23:21:17 +08:00
DDD 思想是一样的，无所谓.NET 还是 JAVA。目前比较系统的书就几本 《领域驱动设计 软件核心复杂性应对之道》和《实现领域驱动》
要么就是 Youtube 上的 视频。 --- 另外我找工作 Java 方向想找个使用 DDD 的团队好难。 |
|
8
WispZhan 2017-09-21 23:24:28 +08:00
@WispZhan 另外上面那两本书里或者说 DDD 概念里很多知识点都是 Martin Fowler 书或者 Blog 里的内容。
|
|
9
WispZhan 2017-09-21 23:27:55 +08:00
|
 |
11
me15000 OP @pming1 感谢提醒，已经找到了，之前也看到 abp 还没弄懂是什么，现在算是明白了，这个就是基于 DDD 的框架
http://www.cnblogs.com/farb/p/ABPTheory.html |
|
13
hantsy 2017-09-22 10:12:42 +08:00
@WispZhan 国内没多少公司会去用 DDD 思想设计软件的，大多数虽然用 Java，C #，连基本的 OOP 概念不够深入。在面对一个项目时，什么业务一上来都能直接与 RDBMS 扯上关系，怎么可能去实现。
|
|
14
hantsy 2017-09-22 10:15:30 +08:00 1
像我上面提及的几个例子，本身业务都不复杂，如果给一些人去看，我可能会听到一句话，“建几个表就解决了，搞得那么复杂，根本就看不懂”。
|
|
16
WispZhan 2017-09-22 10:32:07 +08:00
@hantsy 后知后觉也没什么，经验总结已经足够了。Eric Evans 也是 引用了不少 内容。只能说 Martin 到 DDD 应该是水到渠成，顺水推舟了。只是 Eric 总结的这整套软件设计方法更完善。
最近刚刚准备把 Eric 的 DDD 里引用的《分析模式》拿来读一读。可惜发现中文版已经绝版了。只能硬着头皮看看原版或者收二手了。 --- 确实是这样，今年刚刚到深圳，之前一直在武汉。还是从嵌入式转到 Java 的，目前大概 2 年经验吧。目前面了好多公司，也在几家公司呆过试用期，都是试用期没多久就走了。 原因就是，你说的这些现象。目前接触到的大部分人，不管是什么工作经验的人，基本上就是拿着需求就上代码，对 OOP 概念的理解，也是很糟糕。 特别是最近去的一家公司，居然还是上的微服务，然而服务边界一团糟。关键是强度又大，还天天加班，于是前几天离职了 --- 真的是感同身受 |
|
17
hantsy 2017-09-22 10:44:04 +08:00 5
DDD 更多是理论，只是比 SOLID 具体一些，与 GOF，Patterns of Enterprise Application Architecture 相比，站在一个更高角度分析问题。
我从来不相信用一个具体所谓的 DDD 框架 就能够用好 DDD，它必须是经历长期实践的结果，这些框架永远不会教你去怎么理解具体业务中 Domain，怎么去划分 BoundedContext。同理，我也不相信，用 Spring Cloud 的公司或者个人就懂了 Microservice。 如果要将这些软件开发理论与实践和工具分层，分级（个人观点）： 1. SOLID 2. DDD 3. GOF，Patterns of Enterprise Application Architecture，Refactoring 等 4. Framework，Libraries 等 5. 具体的 API 国内就看到最多的人，什么框架，理论等，在一些人眼里，都只是 APIs。 甚至有一些 [ XXX 内幕] ， [XXX 微服务架构] 的书籍，满纸都是 APIs，贴代码，不讲其背后的设计理念（写书的人很多我相信没什么相关方面的实践），一些书不如叫 [XXX API 中文解释] 更贴切。 |
 |
18
min 2017-09-22 15:41:22 +08:00
ddd 本身概念就比较杂而且庞大，我感觉比较好的学习方式不是去找一个两个好的资料，而是把你能找到的资料都快速通读一遍，反而会有助于理解。
举个例子说微软的 cqrs journey 个人感觉就写得不咋地，万一在上面花很多时间，反而误入歧途。 |
|
19
hantsy 2017-09-22 20:53:43 +08:00 1
@WispZhan 国内大多数公司做项目都这样，乱七八糟的，习惯了就好了。
有些公司上级技术管理层大都也就写了两年程序，本来肚子没什么水，就开始享受领导别人的乐趣，这样的公司那来的技术氛围。 有些技术出身的创始人开的公司对于技术人员可能还是不错的，但对于一些混日子，天天加班讨好老板，写工作报告写得天花乱坠的人可能恰好相反。 但再好的公司，一旦大了，什么鸟都有，即使那些在你心中曾经是好的公司，何况我们几千年官僚文件传统还在。刚开始工作的那几年，都是激情四射，总想把工作做得尽善尽美。结果基本上都是吃力不讨好，你想做得太好，一群人会袖手旁观的看着你做。要么就 V 站常见的那句话，”不要坑队友“，上什么新技术，搞什么模式，能跑就行了，对他们来讲又要面临学习成本。 有机会还是好好挑选一下公司吧，不要工资放在第一位，虽然鱼龙混杂，还是可以发现一些不错的公司。 |
Select Language