摘要：
一、分离查询命令Separatingcommandsfromqueries 早期的面向DDD设计方法的难点是如何设计一个类，这个类要包含域的方方面面。通常来说，任务软件系统方法调用可以分为两类：查询和命令。在这里，查询是指一个系统的和个操作，它不会改变系统的任务值，仅返回一些结果。命令的职责是个性系统数据。如果两组方法都使用相同的域模型，逻辑上可能存在查询和命令分离不明显问题... 阅读全文
摘要：
我们长时间争论什么方案是实现域业务领域层架构的最佳方法。最后，我们用一个在线商店案例来说明，其中忽略了许多之前遇到的一些场景。在线商店对很多人来说更容易理解。 一、在线商店项目简介 1. 用例选择 Use-caseDescriptionRegisterstothesiteTheuserfillsintheapplicationformandbecomesano... 阅读全文
摘要：
一、数据--行为转变 很长的时间，典型的分析方法或多或少是以下两种，第一，收集需求并做一些分析，找出有关实体(例如，客户、订单、产品)和进程来实现。 第二，手持这种理解你尝试推断一个物理(和主要关系)的数据模型，可以支持您确保流程数据模型是关系一致(主键约束、归一化、索引)，然后开始构建软件组件对识别的最相关的业务实体的表 你也可以依靠数据库特定功能，如存储... 阅读全文
摘要：
一、编排业务逻辑的模式1. 事务脚本模式TS（TheTransactionScriptpattern） TS模式概述 TS鼓励你跳过任何的面向对象的设计，你直接到所需的用户操作的业务组件映射。专注于的业务用户可以通过表示层完成，并为每个请求编写方法。这个方法被称之为事务脚本，此处事务通常是指想要进行商业交易，脚本是指系统中的一系列关系用户操作的系统操作。 ... 阅读全文
摘要：
第五节 探索领域架构 一、领域驱动设计的价值与意义 最初在java中使用，.net要晚些才引入。领域驱动设计出现之初的争议。一个向导，少走弯路 1. 我们真的需要DDD吗？ DDD并不适用于每个软件项目，因为他需要掌握一相技能，可有较高的启动成本。也不会因为一个项目简单而阻止你使用DDD，在是否DDD方面有两误区，你觉得使用他很cool，你觉得项目只有稍复杂的CRUD。使用... 阅读全文
摘要：
第一章 基础 第一节 软件架构与软件架构师 简单的说软件架构即是为客户构建一个软件系统。架构师随便软件架构应运而生，架构师是一个角色。 2000年9月ANSI和IEEE发布了《密集性软件架构建议章程》Recommended practice for architectural description 阅读全文