一个通用领域驱动设计的架构性解决方案包含4 个概念层：
将应用划分成分离的层并建立层间的交换规则很重要。如果代码没
有被清晰隔离到某层中，它会迅即混乱，因为它变得非常难以管理
变更。在某处对代码的一个简单修改会对其他地方的代码造成不可
估量的结果。领域层应该关注核心的领域问题。它应该不涉及基础
设施类的活动。用户界面既不跟业务逻辑紧密捆绑也不包含通常属
于基础设施层的任务。在很多情况下应用层是必要的。它会成为业
务逻辑之上的管理者，用来监督和协调应用的整个活动。
例如，对一个典型的交互型应用，领域和基础设施层看上去会这
样：用户希望预定一个飞行路线，要求用一个应用层中的应用服务
来完成。应用依次从基础设施中取得相关的领域对象，调用它们的
相关方法，比如检查与另一个已经被预定的飞行线路的安全边界。
当领域对象执行完所有的检查并修改了它们的状态决定后，应用服
务将对象持久化到基础设施中。
实体
有一类对象看上去好像拥有标识符，它的标识符在历经软件的各种
状态后仍能保持一致。对这些对象来讲这已经不再是它们关心的属
性，这意味着能够跨越系统的生命周期甚至能超越软件系统的一系
列的延续性和标识符。我们把这样的对象称为实体。
