业务逻辑-Domain Model

Domain Model是对现实世界中的业务抽象为类,所以类不只包含数据,还包括方法(现实世界的业务逻辑)。但领域模型不包括数据的存取,一般通过仓储模式将(POCO)对象管理数据。

设计一个复杂的系统,应先将现实世界的业务逻辑分割为不同的界限上下文,其实每个界限上下文对应现实世界的一部分独立业务逻辑,将不同的独立业务逻辑拼成一个复杂系统。现实逻辑与程序界限逻辑对应利于代码管理。

仓储模型

这里用Entity Framwork作为仓储模型,因为Entity Framwork已经是仓储模型,没有必要再包一层仓储接口。

Entity Framwork可通过DbSet<T>获取保存复杂类型(一个业务类型的属性为一个业务类型,这样为属性的类型对应的数据表存在外键

案例

这里以一个银行系统为例

  1. 用户可用开户
  2. 用户可存入、取出、转账,都需要记日志

    代码

    代码[下载]]()

    数据层

    新建Domain.Data类库,通过包安装entity framwork

    定义类

    public class BankAccount
    {
        public Guid BankAccountId { get; set; }
        public decimal Balance { get; set; }
        public string CustomerRef { get; set; }

        /// <summary>
        /// 账户交易记录
        /// </summary>
        public virtual ICollection<Transaction> Transactions { get; set; }

        /// <summary>
        /// 是否有足够余额
        /// </summary>
        /// <param name="amount"></param>
        /// <returns></returns>
        public bool CanWithdraw(decimal amount)
        {
            return (Balance >= amount);
        }
        /// <summary>
        /// 取款
        /// </summary>
        /// <param name="amount"></param>
        /// <param name="reference"></param>
        public void Withdraw(decimal amount,string reference)
        {
            if (CanWithdraw(amount))
            {
                Balance -= amount;
                Transactions.Add(new Transaction() { BankAccountId=this.BankAccountId, Withdraw = amount, Reference = reference,Date =DateTime.Now});
            }
            else
            {
                throw new Exception("");
            }
        }

        /// <summary>
        /// 存款
        /// </summary>
        /// <param name="amount"></param>
        /// <param name="reference"></param>
        public void Deposit(decimal amount,string reference)
        {
            Balance += amount;
            Transactions.Add(new Transaction() { Deposit=amount,Reference=reference,Date=DateTime.Now});
        }
    }  

    public class Transaction
    {
        public int ID { get; set; }
        // 数据库建表为BankAccount的外键
        public Guid BankAccountId { get; set; }
        public decimal Deposit { get; set; }
        public decimal Withdraw { get; set; }
        public string Reference { get; set; }
        public DateTime Date { get; set; }

        public virtual BankAccount BankAccount { get; set; }
    }

数据处理上下文

    public class BankAccountContext:DbContext
    {
        public DbSet<BankAccount> BankAccounts { get; set; }
        public DbSet<Transaction> Transactions { get; set; }

        protected override void OnModelCreating(DbModelBuilder modelBuilder)
        {
            base.OnModelCreating(modelBuilder);
        }
    }

新建MVC站点引用Domain.Data程序集

原文地址:https://www.cnblogs.com/LoveTomato/p/9397566.html

时间: 2024-11-05 11:55:20

业务逻辑-Domain Model的相关文章

拨乱反正:DDD 回归具体的业务场景,Domain Model 再再重新设计

首先,把最真挚的情感送与梅西,加油! 写在前面 阅读目录: 重申业务场景 Domain Model 设计 后记 上一篇<设计窘境:来自 Repository 的一丝线索,Domain Model 再重新设计>. 讲本篇内容之前,先回顾上一篇所讨论的内容,主要是 Repository(仓储)的职责问题,属于领域?还是应用层?其实到头来也没有准确的结论,但是最终比较偏向于仓储定义在领域,实现在基础层,调用在应用层.你可能有些疑问,为什么要讨论仓储的职责问题?看过上一篇的内容你可能会有些答案,这也就

[架构设计] 什么是业务逻辑

讨论设计时,专业词汇满天飞,每个人的技术背景.工作经验上的不同都会导致在理解上存在着差异.无论是SEI的定义.OMG UML的定义.还有各路大神的定义,都有从不同视角带来的差异.准备后面关注这些定义的差异,摊开来大家一起来讨论. 关于'业务逻辑', 国内国外争论了很多年了(这篇在07年就说没有清晰的定义),其中几个比较详细的讨论见附录(一定要看评论).我总结主要分为两类: 一类是逻辑处理论,一类是数据操作论. 逻辑处理论 先看前者,这一类观点,核心是强调逻辑.细说业务逻辑中,作者将业务逻辑分别做

Asp.net设计模式笔记之三:业务逻辑层的组织

本章内容要点: 1.Transaction Script模式组织业务逻辑 2.Active Record模式和Castle Windsor来组织业务逻辑 3.Domain Model模式来组织业务逻辑 4.Anemic Model模式和Domain Model 来组织业务逻辑的差异 5.理解领域驱动设计DDD以及如何运用它让自己专注于业务逻辑而不是基础设施关注点 并非所有的应用程序都是一样的,也并非所有的应用程序都需要复杂的体系结构来封装系统的业务逻辑.作为开发者,重要的是要理解所有领域逻辑模式

设计窘境:来自 Repository 的一丝线索,Domain Model 再重新设计

写在前面 阅读目录: 疑惑解读 设计窘境 一幅图的灵感 为嘛还是你-Repository 后记 上一篇<No zuo no die:DDD 应对具体业务场景,Domain Model 重新设计>. 希望本篇博文废话少点,注:上一篇瞎扯的地方太多. 疑惑解读 先回顾一下,在上一篇博文中,主要阐述的是领域模型的重新设计,包含:真正的去理解领域模型和领域服务的加入(感兴趣的朋友可以看下前几篇来了解一下前因后果.).凡事都有修改的理由,为什么加入领域服务,主要是之前对领域模型的认知不够(实体充当起了伪

细说业务逻辑(一)

内容提要 ===================前篇===================== 前言 内容提要 1.我把业务逻辑丢了!——找回丢失的业务逻辑 2.细说业务逻辑 2.1.业务逻辑到底是什么 2.2.业务逻辑的组成结构 2.2.1.领域实体(Domain Entity) 2.2.2.业务规则(Business Rules) 2.2.3.完整性约束(Validation) 2.2.4.业务流程及工作流(Business Processes and Workflows) 2.3.业务逻辑

细说业务逻辑(二)

3.业务逻辑的架构模式及实现 Martin Fowler在<Patterns of Enterprise Application Architecture>一书中,总结了四种企业应用中业务逻辑的组织方式 :Transcation Script,Domain Model,Table Module及Service Layer,另外,本书的第十章“Data Source Architecture Patterns”中包含一种模式——Active Record.结合软件体系结构的近期发展及个人的理解,

死去活来,而不变质:Domain Model(领域模型) 和 EntityFramework 如何正确进行对象关系映射?

写在前面 阅读目录: 设计误区 数据库已死 枚举映射 关联映射 后记 在上一篇<一缕阳光:DDD(领域驱动设计)应对具体业务场景,如何聚焦 Domain Model(领域模型)?>博文中,探讨的是如何聚焦领域模型(抛开一些干扰因素,才能把精力集中在领域模型的设计上)?需要注意的是,上一篇我讲的并不是如何设计领域模型(本篇也是)?而是如何聚焦领域模型,领域模型的设计是个迭代过程,不能一概而论,还在路上. 当有一个简单的领域模型用例,完成一个从上而下过程的时候,就需要对领域模型和数据库进行对象关系

拨开迷雾,找回自我:DDD(领域驱动设计)应对具体业务场景,Domain Model(领域模型)到底如何设计?

写在前面 阅读目录: 迷雾森林 找回自我 开源地址 后记 毫无疑问,领域驱动设计的核心是领域模型,领域模型的核心是实现业务逻辑,也就是说,在应对具体的业务场景的时候,实现业务逻辑是领域驱动设计最重要的一环,在写这篇博文之前,先总结下之前关于 DDD(领域驱动设计)的三篇博文: 我的“第一次”,就这样没了:DDD(领域驱动设计)理论结合实践:伪领域驱动设计,只是用 .NET 实现的一个“空壳”,仅此而已. 一缕阳光:DDD(领域驱动设计)应对具体业务场景,如何聚焦 Domain Model(领域模

java 业务逻辑理解

细说业务逻辑 2016年10月14日 07:16:28 阅读数:2295 细说业务逻辑   前言 记得几个月前,在一次北京博客园俱乐部的活动上,最后一个环节是话题自由讨论.就是提几个话题,然后大家各自加入感兴趣的话题小组,进行自由讨论.当时金色海洋同学提出了一个话题--"什么是业务逻辑".当时我和大家讨论ASP.NET MVC的相关话题去了,就没能加入"业务逻辑"组的讨论,比较遗憾. 其实,一段时间内,我脑子里对"业务逻辑"的概念也是非常模糊的.