roadtoagility / dflow

DFlow is a Domain-Driven Design platform that provides the infrastructure to organize business logic, design your domain model, deliver domain events and store in different formats.

DFlow - Domain Flow

It is a set of framework to learn, organize and accelerate development of the heart of software.

Package source

<repository url="https://github.com/roadtoagility/dflow" />

Project Informations

Code Quality

CI Status

Breaking Changes in 0.6.3 -> v0.8.0

That is a major refactoring of DFlow to be more "friendly" and have consistent programming model.

• DFlow.Business will be maintained any more
• DFlow.Business.Cqrs will be maintained any more
• DFlow.Domain become DFlow (back to origins :)
• DFlow.Specifications become a separated assembly
• BaseEntity -> EntityBase
• All Events must inherits from DomainEvent abstract class
• There a new interface to raise events, so events can be raised from Entities or via Aggregates as you need.
• DFlow.Domain.Events merged with DFlow and had several APIs changes

About Project

Domain Flow aka DFlow is a very light and opnionated set of frameworks to help implement the hearth of applications based on Domain-Driven Design. There are 3 assemblys organized as described bellow:

• DFlow: Core assembly providing objets to implement Entities, ValueObjects, Validations and Aggregates;
• DFlow.Specifications: It is a Specification Design Pattern implementation;
• DFlow.Persistence: This project depends on DFlow because it is responsible to translate from/to domain objects representation. It is a set os interfaces to materialize domain layer to be persisted in any format that you want. The 3 major patterns implemented are Unity Of Work and Repository.

Addon: DFlow.Persistence. DFlow as based on clean architecture principles, so domain layer aka Entities are first class citizen.

Usage

Referencing DFlow

Creating Domain objects

1. The most basic DFlow business object is the Value Object implementation that allows you follow the principle of non-primitive obsession for the objects you want.

// Value Object
public sealed class Email : ValueOf<string,Email>
{

}

2. Defining and Entity

// Entity
public class User : EntityBase<UserId>
{
    public User(UserId identity, Email mail, VersionId version)
        : base(identity, version)
    {
        Mail = mail;

        AppendValidationResult(identity.ValidationStatus.Failures);
        AppendValidationResult(mail.Failures);
    }

    public Email Mail { get; private set; }

    protected override IEnumerable<object> GetEqualityComponents()
    {
        yield return Identity;
        yield return Mail;
    }

    // DOmain objects can have static contualized api based on factory methods
    public static PrimaryEntity From(PrimaryEntityId id, SecondaryEntity secondary, SimpleValueObject simpleObject,
        VersionId version)
    {
        return new PrimaryEntity(id, secondary, simpleObject, version);
    }

    // Domain Objects can have instance business methods
    // Entities can raise events
    public void Update(Email mail)
    {
        if (!mail.ValidationStatus.IsValid)
        {
            AppendValidationResult(mail.ValidationStatus.Failures);
        }

        Mail = mail;
        RaisedEvent(UserMailUpdatedEvent.For(this));
    }

}

Contributors

• Adriano Ribeiro @drr00t
• Douglas José Ramalho Araujo @dougramalho
• Marco V Gurrola @marcovgurrola
• Zama Bandeira Braga @zamabraga

Supporters

Supporter	Description
	All Products Pack License for Open Source under program Free License Programs

Thanks

A special thank you to Jetbrains for donating licenses to the project.

License

This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0. If a copy of the MPL was not distributed with this file, You can obtain one at http://mozilla.org/MPL/2.0/.

dflow's Issues

Creation of Business Objects are expensive

DFlow has two different types of business object:

• Entities
• Value Objects

Both are responsible for:

• Enforce the existing rules for the concept that they represent, like:

Money internally is a numeric type, and has rules like least value is 0, and maybe a top limit value.

So, for those do we use:

• read-only object rule enforced by private constructors and supported by factory methods
• Existential validations rely on Validator object implement with FluentValidator
• Transport validation error to parent object like Entity via property ValidationResults

We really would like to remove FluentValidator dependency and to have our own implementation of Chain of Responsibility desing pattern but we can't lose factory method object building style.

One thing that could be nice is to concepts like ValueOf library and implement validation integrated to Object construction.

Using Semantic Release Action

@drr00t @dougramalho

I have found this Github Action https://github.com/cycjimmy/semantic-release-action to impove a best way to realese, for use them need to use semantic commit menssage pattern

Develop a publishing workflow

Develop a publishing workflow

Remove dependency of FluentValidation library from Domain

Domain needs to provide just domain modeling tools, no validation relying on an external libraries like FluentValidation.

Remove unused or unecessary folders

.vs/* from root folder

complement nuget information to all project packages

Subscribers shoud have a default implementation

Now we have to do an unnecessary implementation of the method Update in all subscribers

Implement test in the core project

All of our tests are in Example project, do we to test the core and implement all missing classes as default implementations.

remove warnings

What you think about setup warnings as errors on build?

All operations must return an execution result event if it do have data

Define operational events, like:

CommandEvent: atributtes: {status: enum - succed: true | false, exception: ExceptionClass, detail: "additional text information", data: GenericDataType to the user}

Persistence driver to neo4j database