《领域驱动设计精粹》读书笔记之第一章《DDD对我而言》

一些典型的反模式

1. 软件开发被视为成本中心而非利润中心。
   PS：这通常是因为从业务的角度来看，设备和软件技术是必要的的消耗而不是战略优势的重要来源。这种观念会影响管理者对于开发方面的战略投入及重视程度。

2. 开发人员热衷于技术并通过技术手段解决问题，而不是深入思考和设计。
   PS：这可能导致他们孜孜不倦的追逐技术潮流，而忽视业务及技术的合理性，从而进一步造成技术和业务的脱节，舍本逐末，设计逐渐变得混乱不堪，系统变得难以维护。

3. 过于重视数据库，大多数解决方案的谈论都是围绕数据库，而不是业务流程和运作方式。
   PS：数据库设计只是技术实现方式，而不是业务核心，所以它与任何业务模型的讨论和建立都没有关系。

4. 对于根据业务目标命名的对象和操作，开发人员没有给与足够的重视。
   PS：这会导致交付的软件和业务所拥有的心智模型之间产生巨大的分歧，这就要求技术人员和业务人员之间需要有统一的通用语言，否则鸡同鸭讲，相关信息一定会出现失真甚至丢失。

5. 软件中存在错误的抽象级别，表现为开发人员试图借助过度概括的方案满足所有当下以及臆想出来的未来需求，而没有把重心放在解决实际而又具体的业务诉求上。
   PS：过度设计是一种严重浪费，脱离业务的开发没有任何意义。

设计的重要性

设计是否必要或是否负担得起，这个问题根本没问到点子上，设计是不可或缺的，除了优秀设计就是糟糕设计，根本不存在“不做设计”一说。

如果担心周祥的设计会带来高昂的软件开发成本，那么设想一下，将来为了维护甚至修缮一套糟糕设计的软件就需要付出更为昂贵的代价。特别是当我们把软件作为与同行竞争的优势时尤其如此。
PS：不做设计的开发就是耍流氓。

软件建模的两种方式

短期项目

短期项目所承载的业务具有相当的时效性，这要求团队快速地实现并上线，以获取更大的商业价值。这类模型我们提倡只做最基本和最简单的思考。

长期项目

组织应将其作为战略核心并对其长期投入，这将要求团队适度地进行有效设计，不仅要考虑当下的交付规划，还要适当兼顾兼容性、可扩展性等未来的设计要求。这类模型需要业务人员和开发人员充分地展开讨论与分析。

PS：基于上述两种方式，项目定制需要和产品进行严格程度的有效分离，包括数据库设计。

应该怎样做

追求有效设计

有效设计既可以满足商业组织希望借助软件超越竞争者的诉求，又可以驱动企业去思考哪些核心业务必须成为其竞争力，还可以指引构建正确软件模型的方向，有效设计简洁而非冗余。

应用领域驱动设计

充分学习和利用领域驱动开发中的战略设计和战术设计进行软件建模，以系统性的方式对软件进行全生命周期的设计和管理。